progress bottom bar is ugly when launch splinter

[regina_kim]

kernel : 20080705-asu.stable-uImage.bin
rootfs : 20080708-asu.stable-rootfs.jffs2

summary : progress bottom bar is ugly when launch splinter

step :

1. home screen
2. press splinter

current result : progress bottom bar is ugly

expected result :bottom bar should be same as other application

[jeremy]

It may be because launching high-loading application like splinter, it will affect the animation of the bottom panel of illume launcher.

[will]

raster, do you know whats going on here?
it does look kinda nasty..

[raster]

that's not the "bottom progressbar". it is in fact splinter. splinter's window is up and visible, just splinter has not drawn anything yet. thus anything that moves or changes on top of splinter will leave the previous contents of the framebuffer there until splinter redraws. this is not a bug and not something you are going to do a lot about easily. you could try delay splinters window opening - use a timer or idle_enterer you remove later (that will get called after ecore's idle_enterer that will end up doing the first draw)... but really... not worth hacking around. the real long term solution is to have a proper compositing environment that knows when things draw and don't draw... anyway. i can go on. as such it's not a bug. it's just how the display system works when an app has not responded to an exposes event - splinter does respond, but it is busy loading data from disk in order to draw.

[will]

that sucks...

[raster]

thats how it has ALWAYS been in X - in fact in almost all windowing systems. windows included since the 1980's. if a window is set to have "no background" its background is not redrawn at ALL until the application handles the redraw. this is to be more efficient. instead of filling the window with a color THEN drawing it again (2 draws) you only do 1 draw - when the app gets to doing the draw. we don't have a composited environment where we can syncronise draws and FORCE a window not to be drawn until the first actual draw by the application for example. compositing is EXPENSIVE though. it consumes lots of ram - LOTS, decreases performance as you now have to draw to a backing pixmap ALWAYS then "composite" the pixmap to the real screen. with fast enough hardware this isn't bad - but we don't have that. (this is why i i have been hoping for either many fewer pixels so we can composite in software, or a much better graphics solution than the glamo). this then gives us the raw tools to consider compositing (not including an accelerated driver to handle the alpha blending etc. etc.). :)