On 9/26/06, Matt Lavin <[EMAIL PROTECTED]> wrote: > Thanks for the quick response. I had thought about using > gdk_window_begin_paint_rect and gdk_window_end_paint but that will cause > the data on the screen to be erased, right? I would love to be able to > draw directly on top of whatever is currently visible to the user. Do > you know if that is possible? >
As far as being erased it should not under directfb gdk I use the system back buffer. Under X11 yes it would. You can also get the handle to the DFBWindow and work with it directly. Just leave it in the same state I do by default I think locked but can't remember :) But this is what begin and end do. I think your solving the problem wrong. Generally if you want to overscan you need your paint proc to have a hook to the overscan code if the hook is not null this will be painted on top of the regular rendering. This can be done in a number of places I've not seen your code. This way if a expose does come through for a number of reasons your not going to lose your drawing. Blinking text cursors animated gifs etc etc all will blow away what your trying to do even the cursor will mess this up. You can create a borderless window with alpha on top of the place you want to overscan and draw in that. There are numerous safe ways to get this effect without trying to do it the way your suggesting. > Mike Emmel wrote: > > You can draw outside of a paint event you just need to place > > gdk_window_begin_paint_rect/end drawing calls around the code. Don't > > forget to call > > gdk_flush() after end its a no-op on directfb but required for X11 if > > you wan't to > > see anything under X. > > The above model maps nicely to directfb and better works on all > > platforms. > > > > gdk_window_begin_paint_rect > > ...draw stuff > > gdk_window_end_paint > > gdk_flush > > > > If you call the above outside the paint thread have fun with enter/leave > > you probably will find all my deadlock problems. > > > > You can also if you wish send exposes and call > > gdk_window_process_updates which is in my opinion cleaner. > > > > gdk_window_invalidate_rect > > gdk_window_process_updates > > gdk_flush > > > > > > Drawing outside the expose handler given you have > > gdk_window_invalidate_rect/process_updates does not make a lot of > > sense. Its quite fast and works all the time the only cost over > > begin/end > > is allocation of the expose event and insures you are not cleared by > > system expose events. > > > > What motivated the change is for directfb its the wrong drawing model. > > It was really a artifcact of the original GTK/X11 implementation that > > you could > > do this. There are a thousand reasons to not allow a ui toolkit to > > assume it is possible to draw to the screen without guard calls. X11 > > got it wrong the original port tried to emulate the X11 way leading to > > poor performance since you flipped on every draw op now Gtk has moved > > away from this model. > > > > Mike > > > > > >> _______________________________________________ > >> directfb-dev mailing list > >> [email protected] > >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > >> > > > > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
