Recent Features
| |||||||||||||
Timer slack for slacker developersTimer slack for slacker developersPosted Oct 18, 2011 3:12 UTC (Tue) by jcm (subscriber, #18262)Parent article: Timer slack for slacker developers
By the way, I've been reading the X11 protocol specification recently (not so found of the newer desktops and want to learn enough to feed myself). In X11, applications receive Expose events every time a window configuration event happens or a window is partially or completely covered or uncovered. Most decent toolkits should react appropriately by not redrawing non-visible parts of the window, so I'm curious to know what Peter is referring to here.
(Log in to post comments)
Timer slack for slacker developers Posted Oct 18, 2011 3:52 UTC (Tue) by neilbrown (subscriber, #359) [Link]
I'm not Peter so I can only guess.
But applications tend to update a widget, and then let the tool kit render the widget to the screen.
A clock, for example, might have a 'label' widget and wake up every second to 'strftime' the time to a buffer and then label.set_text(buffer). That will update some internal state and tell the server to "invalidate" the relevant region of the window. If the window is visible, or subsequently when it becomes visible, the X server sends an 'expose' event and then the tool kit renders the widget to the window.
The application is oblivious of the fact that the label never actually makes it to the display. It just keeps on wasting power generating labels that are never seen.
It could find out though. It could connect to the "expose" event and only continue updating while the expose events are coming in.
Getting this smooth and jitter free might be tricky. For a simple widget it should be sufficient to wait for an expose, then calculate and set the image, then let the tool-kit draw it. Then when the next event (e.g. timer tick) says that the image should change, you just invalidate the window and stop the timer. Don't bother drawing or listening for further notifications until the expose happens.
However for rendering that is more complex doing it that way might be too slow. You might have to put up a "waiting" image when you get an expose after a long idle period, spend 500ms generating your image, then render it and have the next one ready before invalidating the old one.
e.g. a GPS tracker might not even bother down-loading maps when the window is not exposed. But when it gets an expose event in a new city, it cannot create a correct render straight away, and should not present and out-of-date render. So you have to wait for a while. This presents the classic trade-off. We save power by not updating regularly, but the cost is latency when we want to re-activate.
So it is possible, but it could be a bit messy. Extra tool-kit support would probably make it smoother. And there is probably some tool kit that already makes this really easy and I'm looking forward to someone telling me which one.
Timer slack for slacker developers Posted Oct 18, 2011 14:40 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
> The application is oblivious of the fact that the label never actually makes it to the display. It just keeps on wasting power generating labels that are never seen.
> > It could find out though. It could connect to the "expose" event and only continue updating while the expose events are coming in. > > Getting this smooth and jitter free might be tricky.
Actually this isn't as bad as it sounds. The application can query the visibility state of the widget's window (and get notified when it changes), so it just has to keep a binary "on/off" state for updates. (I can't remember without checking whether there is a simple way to get information about which parts of a partially visible window are shown, but that would be much less important.)
Timer slack for slacker developers Posted Oct 18, 2011 21:25 UTC (Tue) by neilbrown (subscriber, #359) [Link] It probably isn't as bad as I made it sound. I don't think the 'visibility state' (notified by "mapped" and "unmapped" events) is really enough because it doesn't tell you when a window is fully obscured by another window. However it wouldn't be too hard to synthesis a simple binary state for the whole window by watching expose events. And you don't really need to put up a "waiting" image like I suggested - just do what firefox does and leave the contents of the screen like they were before - firefox window decorations wrapped around 2 xterms and an xclock which isn't ticking any more :-) To play with mapped events, try:
#!/usr/bin/env python
import gtk
w = gtk.Window()
w.show()
def mapped(w,ev):
print "mapped"
def unmapped(w, ev):
print "unmapped"
w.connect('map-event',mapped)
w.connect('unmap-event',unmapped)
w.connect('destroy', lambda x:gtk.mainquit())
gtk.mainloop()
Timer slack for slacker developers Posted Oct 19, 2011 8:03 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
> I don't think the 'visibility state' (notified by "mapped" and "unmapped" events) is really enough because it doesn't tell you when a window is fully obscured by another window.
Actually I thought it did:
"When the window changes state [...] to viewable and fully obscured, the X server generates [a VisibilityNotify event] with the state member of the XVisibilityEvent structure set to VisibilityFullyObscured." [1]
(Hope I'm not getting too boring here!)
[1] http://tronche.com/gui/x/xlib/events/window-state-change/...
Timer slack for slacker developers Posted Oct 18, 2011 5:09 UTC (Tue) by geuder (subscriber, #62854) [Link]
> In X11, applications receive Expose events every time a window configuration event happens or a window is partially or completely covered or uncovered.
Traditionally yes. However, I believe to remember that at least one existing compositing window manager does not offer this nice functionality. So the application will update its window even when not visible.
Disclaimer: I don't remember the details. And if I did, I would probably be hindered by an NDA to get more detailed.
Timer slack for slacker developers Posted Oct 18, 2011 5:20 UTC (Tue) by jcm (subscriber, #18262) [Link]
Fortunately I explicitly don't care about compositing window managers :)
Timer slack for slacker developers Posted Oct 18, 2011 9:31 UTC (Tue) by dgm (subscriber, #49227) [Link]
Unfortunately, you live in a world where most people do.
Timer slack for slacker developers Posted Oct 18, 2011 15:01 UTC (Tue) by jcm (subscriber, #18262) [Link]
http://www.amazon.com/gp/product/B002TYEPWO/ref=dm_dp_trk...
I've decided there are plenty of things I enjoy about living in the present, but X11 is an area where I'm going to force a return to the 80s. I want a network transparent non-3D desktop that just works. I used to care about pretty window managers and all that nonsense, now I just want to get stuff done with my computer and have it otherwise left alone.
Timer slack for slacker developers Posted Oct 18, 2011 16:08 UTC (Tue) by nix (subscriber, #2304) [Link]
Quite so. The pretty stuff is very pretty but every new bit of it seems to break something old that Just Worked until now, because nobody uses network transparency / nobody cares about power consumption / nobody cares about video playback / nobody cares about focus-follows-mouse / nobody cares about any older X extensions / ...
(OK, that *was* excessively cynical.)
Timer slack for slacker developers Posted Oct 18, 2011 17:08 UTC (Tue) by jcm (subscriber, #18262) [Link]
Can be summarized as "I want a UNIX workstation and not a pretty desktop". I don't mean to sound offensive but I actively do not want any of that other stuff. I just want a 1980s style X11 workstation that works exactly as it always did, with X forwarding just working, and none of this 3D stuff. Sure, having extensions to play games is nice and all, but I don't need to rotate my desktop on a cube or have wobbly windows. I used to think I do, but that's before I realized I'd rather have a super boring UI that is set in stone. I want to do something and it always works just like it always did.
Timer slack for slacker developers Posted Oct 18, 2011 23:16 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
I have similar goals, but I'd like Wayland so that I could (do what is essentially) moving *windows* between X servers instead of having windows rooted in the $DISPLAY they started with. The xpra tool can sort of do it, but it's still rooted to some other display and AFAICT doesn't really give the full power of, say, XMonad (happy to be wrong though) over the xpra windows. Combine this with per-application freeze and thaw that came up a few weeks ago that works between different machines and I can migrate a running system to another machine :) .
Timer slack for slacker developers Posted Oct 20, 2011 22:30 UTC (Thu) by nix (subscriber, #2304) [Link]
I'd describe that as "I want a Unix workstation and not *just* a pretty desktop". The pretty is all right, but only if it doesn't break other stuff on its way. "Pretty" is less important than "works".
(But I know we are weird this way. Emacs versus vi is one thing, but most people would look at both of those and run screaming back to their pretty Eclipse. Actually, no, most people would run screaming back to Word, which is neither pretty nor functional...)
80's X - was: Timer slack for slacker developers Posted Oct 18, 2011 21:08 UTC (Tue) by neilbrown (subscriber, #359) [Link]
I think the modern spelling of "network transparent" is "HTML5". However I find that xterm<->tmux provides a very usable 80's style windowing environment over a simple ssh connection.
Oh wait ... I don't think we had ssh in the 80's :-)
80's X - was: Timer slack for slacker developers Posted Oct 18, 2011 22:12 UTC (Tue) by jcm (subscriber, #18262) [Link]
Yea but...HTML5 is the example folks give when told that Linux as a consumer OS doesn't have a stable platform for third party applications. They say "oh, but in the future...HTML5...hand wavy!" and all that. Conveniently forgetting that this was the future for iPhone right before Apple had to about-face and offer real apps. HTML5 and friends might be the future, but that future is further away than most think it is.
It's true we didn't have ssh in the 80s. Nor did we have Xinerama and lots of other things I do like, all of which are iterative improvements on what went before :)
Timer slack for slacker developers Posted Oct 18, 2011 9:32 UTC (Tue) by smurf (subscriber, #17840) [Link]
Well, it's not that easy. Your window may be covered, except that the user presses Alt-Tab and expects to see current content (clocks, download managers,
). Or it may be covered by something that's almost, but not quite, opaque.
That's not the problem, though. The problem is that you can't depend on every program to get this right, but, on the other hand, you do need some way for a program to tell the kernel that when it says 0.2sec it MEANS 0.2sec and not something random that may be roughly of the same order of magnitude. Or not.
How exactly to do that is the kernel people's problem. New scheduler class, new kind of timer, whatever.
Timer slack for slacker developers Posted Oct 29, 2011 18:50 UTC (Sat) by JanC_ (guest, #34940) [Link]
If the Window-switcher knows how to tell the application that it's "exposed" again, Alt-Tab shouldn't be a problem, I suppose?
|
|||||||||||||