Ticket #1593 (closed defect: invalid)

Opened 10 years ago

Last modified 10 years ago

progress bottom bar is ugly when launch splinter

Reported by: regina_kim Owned by: jeremy
Priority: low Milestone: Om2008.8
Component: Locations Version:
Severity: normal Keywords: must have
Cc: testing@…, raster@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

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

Attachments

Screenshot-5.png (47.3 KB) - added by regina_kim 10 years ago.

Change History

Changed 10 years ago by regina_kim

comment:1 Changed 10 years ago by roh

  • Owner changed from jeremy@… to jeremy

comment:2 Changed 10 years ago by jeremy

  • Priority changed from normal to lowest

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

comment:3 Changed 10 years ago by will

  • Priority changed from lowest to low
  • Cc raster@… added
  • Keywords must have added

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

comment:4 Changed 10 years ago by raster

  • Status changed from new to closed
  • Resolution set to invalid

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.

comment:5 Changed 10 years ago by will

that sucks...

comment:6 Changed 10 years ago by 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.). :)

Note: See TracTickets for help on using tickets.