Actually, it's less than 10 kb that is getting transferred. And the round-trip is more like 50 ms, because i'm close to our data-center. (but 200 ms is a safe worst case estimate)
But the stuff is loaded on demand, which actually adds about 200 ms extra to the initial loading time (until it is visually done loading). Since a lot of the stuff is drawn on screen _after_ communication with the server. (and off course after it loads the compiled javascript file, which is itself another roundtrip) This suggest, just creating all the widgets I use once, and cycle them through a bunch of states (without rendering them) at the beginning could save about 200 ms for the 'nice situation of quick roundtrips'. But it wouldn't do too much when the round-trip time is worse. In short: the theme still uses way too many separate image files. Greetings, Ralf 2010/8/11 Ralf Nieuwenhuijsen <[email protected]> > Hi Tron, > > Thanks for your explanations! > I got the image-combining working with the icons I use. > But I cheated a little: a copied the ones I use to my resource folder. (and > gave them more sane names for how I use them as well, so this is a good > thing) > > Yet there are still about 20 small image files loaded that are used by the > theme. Stuff for input fields, buttons, tabs. > This seems like an insane default. And some of these images are already > combined. Can I combine already combined images? > > Why not just reduce it to say three images for the whole 'modern' theme? > A monochrome image, a blue image and a gif image. > > Because 20 round-trips, with the common connection limit of 2, means we're > 20 * 200 ms = 1.8 sec initial loading time. > Just for the round-trips. It's about 40 kb that is getting transferred. > This just seem insane. > > And it will likely increase when I add more functionality. I'm not even > using all of the qooxdoo framework yet. > > Greetings, > Ralf > > 2010/8/9 thron7 <[email protected]> > >> >> >> On 08/09/2010 01:17 AM, Ralf Nieuwenhuijsen wrote: >> > Hi all, >> > >> > I'm fighting with the generator. I don't think I'll even understand how >> > to deal with the 'internal' resource. >> > There is so much path aliasing by default, at so many different places. >> >> The central thing to understand is the idea of the "resource id". For >> every resource, this is simply the path suffix after the usual >> "source/resource" folder. So if you have in your app a resource under >> "source/resource/myapp/myicons/icon.png", its resource id is >> "myapp/myicons/icon.png". Mind that the name space is always included in >> the resource id. >> >> You would then use this resource id both in #asset hints as well as in >> your app code. >> >> >> >> > >> > By default the icon-paths are translated correctly in the >> > source-version, but not in the build version. I've tried assets like: >> > >> > #asset(icon/${qx.icontheme}/*) >> > #asset(icon/16/actions/*) >> > >> > .. but it doesn't seem to help. >> >> The arguments to the #asset hints don't seem to start with a name space >> name (I don't presume you have named your application "icon"). So >> whatever it is you want to include, it has to start with a name space, >> like >> >> #asset(myapp/icon/16/actions/*) >> >> If, as you say, you are mimicking the qooxdoo resource id's, you need to >> mimick the paths under QX/framework/source/resource. You can even use >> "qx" as the name space for your own resources if you want to shadow the >> original qooxdoo resources, as resources from your application are given >> precedence over resources with same id in used libs. So if you want to >> shadow, say, the "folder open" icon from Tango, you could add this file >> to your application: >> >> source/resource/qx/icon/Tango/16/places/folder-open.png >> >> The thing that might have confused you might be that framework code >> doesn't use resource id's directly (as they tend to get long), but uses >> simple aliases handled through the Alias Manager. But you can completely >> ignore that for your own code if you like. Resource aliases *always* >> resolve to resource id's. >> >> >> > >> > Also, I would like to combine the icons into a single image. Does anyone >> > have a simple configuration example, where they do that exact thing? >> >> The Feedreader combines its own icons, see its "image.json" config file, >> its rather terse compared to the framework one. >> >> > Combining the images of the default icon-set? >> > Do I need to replace all the paths in my code? (since i'm technically >> > rewriting the qx/icon paths, which are rewritten to qx/icon/Tango/ ) >> >> It really has nothing to do with your code. Combining images is totally >> transparent for the code using the images. It's only a run-time >> optimization that is resolved during generation and at run time. >> >> > >> > I really don't know where to start. >> > Perhaps combining the icon sets by default is a smart idea? a >> > tango-16.png, a tango-22.png, etc. >> >> I wouldn't bother with combining before you have the basics straight: >> >> - adding images to your app's resource folder ("source/resource"); don't >> forget the leading name space, and you can shadow 'qx' resources >> - using these images in your app code using their resource id >> - using these images in #asset hints, using their resource id (or file >> globs thereof); this assures they get copied into the build version >> >> T. >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > >
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
