Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
emmanuelulloa

What is your layout technique for GSAP?

Recommended Posts

Can you share your methodology for HTML and CSS when working banners.  You know, the non-GSAP part?

I usually chop up the PSD to get my images. I name images as I will reference them on CSS, HTML and JS; so product.png will be <div id="product" class="animated"><img src="product.png" /><div> then on CSS I will have

.animated { display: block; position: absolute;}

#product { left: 10px; top: 35px;}

Then when the layout is done I start the GSAPing from there.

 

Link to post
Share on other sites

I think a popular method is to export your assets from Photoshop including the whitespace. So all your assets have the same size as your stage and are positioned at top: 0px and left: 0px. Most simple animations will work and with a bit of luck you just have to export the new assets for the size adaptions.

Link to post
Share on other sites

... and when you are creating complex 300x600 HiDPI retina ready banners, you will finish with 20 x 600x1200 images?

Link to post
Share on other sites

Yes, the images are just a little bit bigger than the alternatives because they are most of the time PNGs.

And of course this is not the holy grail for every type of campaign. But for standard campaigns with many size adaptions it's working well.

Link to post
Share on other sites

Must be difficult to rotate these assets. I think You have to determine their transformOrigin somehow. I saw this solution just after Flash was killed. Hard to win the battle versus slicing + CSS positioning with bare PS + Sublime.

Link to post
Share on other sites

If you want to rotate an asset you don't use this technique of course. It's just another technique in your toolbox for standard animations with position and opacity

Link to post
Share on other sites

I don't do banners, so maybe I missing something obvious here,  but after exporting everything with the whitespace, couldn't you use a texture packer? 

 

You assets will packed like sardines...

MBfZqUV.png

 

But's that fine because the json file has all the information needed to restore your images to their original position, so figuring out a transform origin for rotation shouldn't be a problem.

 

See the Pen bqEamV by osublake (@osublake) on CodePen

 

 

Link to post
Share on other sites

This is a fine solution but, some adServers wont' allow .json files so the data must be embedded in the html.
Other problem is when you pnquant an image, the size of the transparent area and the colors of the various packed images affecting the overall quality of the 8bit .png as i noticed. ( can be fine with Christoph's transparent jpgs )

Since Google messed up the background-image displaying of Chrome I switched back to simple <img> tags, which means the only way to split up a spriteSheet is via js+canvas pixel manipulation, which can be slow, but possible. Because of these, it seems like the separate Base64 encoded, inline .pngs in <img> elements is the simplest way. This adds ~1.33% file size overhead, but removes all the asset http requests and the quality of the .pngs are the maximum possible.

  • Like 1
Link to post
Share on other sites
2 hours ago, Oliver16Years said:

This is a fine solution but, some adServers wont' allow .json files so the data must be embedded in the html.

 

By json, I just meant the data. The format doesn't matter. I'm using a regular JavaScript object in that demo. This is where the frames variable comes from.

https://s3-us-west-2.amazonaws.com/s.cdpn.io/106114/fighter3.js

 

I haven't looked at optimizing a sprite sheet with with pnquant. I uploaded some sprite sheets for @Christoph Erdmann to look at to see what he would recommend.

 

And I honestly had no idea that using a background image was a common practice until @Web Dizajner asked a question about it.

But you don't need to use a background image to split an image up, nor do you have to do any pixel manipulation. Just draw the sprite on a canvas using the context.drawImage() method, and then convert it to image data using the canvas.toDataURL() method. It's really fast and simple.

 

 

 

 

  • Like 2
Link to post
Share on other sites

As I see now transparent .jpg sprite sheets could be an optimal solution to store all the graphical elements of an ad.
If we could automatically add more quality to red areas ( they are often blocky ). Then we export all the assets in raw 32bit .png format, pack them into a single spritesheet, separate it's transparency into a grayscale .jpg and it's rgb values into a non transparent .jpg, load them in the ad, reassemble the rbg values with alpha values, split them with canvas and json data, and finally put them into <img> || <canvas> elements.

Link to post
Share on other sites

I just guessed the mechanism of compress-or-die. It can be really helpful for most people. The .jxs uploader is really a nice and generous part Christoph. :) The downside for me is: i can only use MIT/free licensed binaries or .js code in my engine. So If I decide to use .tjpg spirtesheets, I have to write the exporter from the available free and offline parts.

Link to post
Share on other sites
12 hours ago, Christoph Erdmann said:

This is what compress-or-die.com does.  :-D

... except the funky sprite generation part. :D

 

Think we are highjacking this thread. :D

 

  • Like 1
Link to post
Share on other sites

I used to do spritesheets and then use backgrounds within divs.

Now I'm using img's inside divs, I found this easier to update assets and create resizes.

I must point out though that the spritesheets were updated manually and not using any good workflow (like SASS).

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×