It's not clear to me what you want to achieve, but you want to separate between a preparation step, where you transfer your data into a suitable for for direct drawing, and the actual drawing, which takes place in expose event.
Consider e.g. my vector drawing program giv handles several hundred thousand vector elements. In the expose event I loop over the list of elements and whatever intersects the expose rectangle gets painted into an offline buffer. Once finished the off-display buffer is shipped to the screen. If additional expose events have not changed the exposed area, I then have an optimization step that simply copies the off-display buffer to the display. I agree that the strategy somewhat breaks down when the number of elements increase even further, and I have thought that it would make sense to store the elements in a quad tree and perhaps multi-hierarchical, but I haven't gotten that far yet. But, if you in your case, need to paint less than a hundred thousand elements, then just paint them directly through cairo in the expose event. You may also want to consider one of the canvas widgets, e.g. goocanvas to help you out. Regards, Dov 2009/1/31 Douwe Vos <dmvos2...@yahoo.com> > As far as I could retrieve from the different forums and on-line > documentation it is possible to draw outside the expose-event but all point > out that its better to draw via the expose event. Currently this is a > problem for my paint algorithm as a complete model is being updated with > information of which parts to draw and which not. So i.e: I have an object > that has a flag if its painted or not. The normal flow would be: > > Immediate paint > if paint flag of object is set then > draw object > mark object as painted > endif > end immediate paint > > > expose paint > if object intersects with the clip then > draw object > endif > end expose paint > > > In an ideal world I would mix them together and would get something like > > paint > if paint flag is set of object intersect with the clip then > draw object > if not an system generated expose event *** > mark object as painted > endif > endif > end paint > > Unfortunately I can not test on the condition marked by the ***. Removing > that condition could in some cases mark the object as painted though it was > only partially painted (as a result of a clip) by the expose event. > > Considering this problem I have the next questions: > > 1. all the immediate drawing is done as a result of a key- or mouse-event > (so no extra thread). Isn't the event-dispatcher for the key- and > mouse-event handled by the same thread as the expose-event dispatcher (or > even they are the same event-dispatcher?). So if that is the case then am I > not running a single threaded program and therefore the immediate drawing > should not interfere with the expose event drawing? > > 2. Is it somehow possible to add extra info to an expose event so I my > expose-event-handle can at least detect that the event was the result of a > call to invalidate originating from me and not from the system? > > 3. gdk_flush, gdk_display_flush, gdk_display_sync I can call whatever I > like these do not seem to work. gdk_window_begin_paint_rect and > gdk_window_end_paint_rect just these appear to be more of the kind 'clear > the area with the background color'. Is there maybe another hidden function > which could solve my problem ? > > Regards, > Douwe Vos > > > > _______________________________________________ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list >
_______________________________________________ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
