On Fri, 1 Feb 2008 16:37:33 +0100 Sanel Zukan <[EMAIL PROTECTED]> babbled:
> Carsten Haitzler wrote: > > * do not delay my output to try coalesce rendering updates (if the composite > > manager is smart and tries to delay updates by like 0.1 or 0.2 seconds from > > xdamage events to try and wait for more updates to occur so it can update to > > screen in 1 go and not in lots of small updates, making window re-draw look > > Hm... isn't the point of xdamage (and the family) to do a lot of small > but precise updates? the point of xdamage is simply to deliver events stating which rectangular region(s) of a drawable have been drawn to - when they are drawn to. it is up to the CM as to what to do with them. generally speaking the CM will then pretty much instantly queue up redraws for he corresponding regions on the real screen. a lot of apps will update their window by drawing all the parts that change. if they do not double-buffer theme selves they will draw directly to the front-buffer. this means that to draw a button that goes from light red to deep pink and looks pressed-in, it may very easily draw a new base color, then draw the lines surrounding the box to make it look indented, then redraw the label in the middle. in theory this can easily be half a dozen or more damage events for the same region. if the CM simply draws on every damage event - u'll get lots of extra compositing going on. if its smart it will queue updates and wait until all damage events have been read then update. if it gets really smart it may even delay a bit then as more damage events may be on their way but not in the buffers yet. it may also wait until vsync sometimes such extra delays that are artificially added beyond draining all damage events could lead to bad sync. situations - eg - video players. they will update the whole video at once anyway. so for apps hat are "smart" about drawing and double-buffer themselves, and care about getting updates up ASAP - set a property. for "legacy" or "stupid' apps - the CM can play some heuristics games by adding small delays to gathering all damage events to make sure it queues up as many as it can for 1 on-screen update to improve smoothness of screen updates as much as possible. > > "smoother" as it happens at once and not bit by bit, but some apps - like > > video players and games, will definitely not want this as they probably do > > whole updates in 1 go anyway). > > So, you are proposing removing delay in updates or waiting for a larger number > of events and update everything in once or maybe signaling cm to do > update for the whole screen, e.g. when video player goes fullscreen? > (I didn't understaind this well) no - see above. it's a hint that says "if you have some smart stuff that may delay an update more than it could be delayed, to try and reduce updates, please don't do this as it's pointless for me because i already am smart about drawing". :) > > * please provide a solid background even if my window is ARGB because i am > > allowing the wm border/decoration to define the backing of my window and the > > contents should be composited over whatever backing the WM provides (the > > problem with window decorations is that they are separate from window > > background. it is impossible to reliably have a titlebar seamlessly continue > > into the app window with textures, patterns, shading etc. without > > fastidiously fixing up themes/widgets/whatever of every toolkit. if > > toolkits were to render to ARGB dest windows and simply NOT render a > > background color/pattern for the window, but leave it transparent with all > > buttons, other widgets, labels rendered onto a dest-alpha transparent ARGB > > window, then the window content is a composited overlay on top of a window > > frame "Decoration" that also defines the decorations UNDER the window > > contents, allowing for smooth transitions from titlebars and borders into > > the window contents). > > But, this sound for me more like a toolkit issue. I'm not sure how > gtk/qt/others will adopt this, but I'm sure this will not go easily in FLTK > (except if I create my own branch). it is a toolkit issue. *IF* the toolkit renders ARGB and is expecting the CM/WM to provide a backing image that is part of the frame/border, then the CM/WM knows to provide this as opposed to thinking the ARGB window is intended to be transparent over other windows. this allows for the background to be seamless with the window frame and match properly. nothing does this (yet), but it'd be very useful if available and later used by toolkits. adopting is easy if ARGB visual window, draw background with alpha of 0x0, instead of 0xff+color. the rest is the same :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list