Re: gnome canvas item apears black on GTK-DirectFB
Hi I have not been able to find out the fix that u mentioned in quartz backend; in gtk+-2.10.14; could u elaborate on that please? It will be very helpful; Thanks Regards sv. On Mon, Jun 9, 2008 at 6:07 PM, svalbard colaco [EMAIL PROTECTED] wrote: Hi Paul Davis , Thanks for your prompt reply ; Can u tell me where exactly the changes have to be done? As u mentioned there is a fix in quartz ; can u elaborate on that ? where in the source code i can find it ? Could i provide a similar fix on DirectFB stack or should i use that the mentioned function in the appllication code itself ? Awaiting for your inputs... Thanks Regards sv. On Mon, Jun 9, 2008 at 5:14 PM, Paul Davis [EMAIL PROTECTED] wrote: On Mon, 2008-06-09 at 16:00 +0530, svalbard colaco wrote: Hi all, I have an application running on GTK-DirectFB and its observed that , a part of the window, which is a gnome canvas item is not rendered properly rather that entire vbox appears black, But when i click on , on a click_to_ add canvas item within that vbox it appears white as expected. this happens on the quartz backend too, and is caused by the non-standard update model used by the canvas. there is a relatively simply fix on quartz. in the paint() function, the canvas should not be delivery expose events to itself, but instead should call gdk_window_invalidate_region(). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gnome canvas item apears black on GTK-DirectFB
On Mon, 2008-06-09 at 16:00 +0530, svalbard colaco wrote: Hi all, I have an application running on GTK-DirectFB and its observed that , a part of the window, which is a gnome canvas item is not rendered properly rather that entire vbox appears black, But when i click on , on a click_to_ add canvas item within that vbox it appears white as expected. this happens on the quartz backend too, and is caused by the non-standard update model used by the canvas. there is a relatively simply fix on quartz. in the paint() function, the canvas should not be delivery expose events to itself, but instead should call gdk_window_invalidate_region(). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gnome canvas item apears black on GTK-DirectFB
Hi I have not been able to find out the fix that u mentioned in quartz backend; in gtk+-2.10.14; could u elaborate on that please? It will be very helpful; Thanks Regards sv. On Mon, Jun 9, 2008 at 6:07 PM, svalbard colaco [EMAIL PROTECTED] wrote: Hi Paul Davis , Thanks for your prompt reply ; Can u tell me where exactly the changes have to be done? As u mentioned there is a fix in quartz ; can u elaborate on that ? where in the source code i can find it ? Could i provide a similar fix on DirectFB stack or should i use that the mentioned function in the appllication code itself ? Awaiting for your inputs... Thanks Regards sv. On Mon, Jun 9, 2008 at 5:14 PM, Paul Davis [EMAIL PROTECTED] wrote: On Mon, 2008-06-09 at 16:00 +0530, svalbard colaco wrote: Hi all, I have an application running on GTK-DirectFB and its observed that , a part of the window, which is a gnome canvas item is not rendered properly rather that entire vbox appears black, But when i click on , on a click_to_ add canvas item within that vbox it appears white as expected. this happens on the quartz backend too, and is caused by the non-standard update model used by the canvas. there is a relatively simply fix on quartz. in the paint() function, the canvas should not be delivery expose events to itself, but instead should call gdk_window_invalidate_region(). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [compiz] color management spec
Added gtk-devel-list@gnome.org to hear their opinion about this matter. For reference, this is what I proposed: http://lists.freedesktop.org/archives/xorg/2008-May/035772.html Danny Baumann wrote: Hi, I strongly dislike supporting subwindow ID/profile tuples. The task of window and compositing managers is and always has been to manage and draw _toplevel_ windows, not subwindows. I don't really think that adding a subwindow management infrastructure to compositing managers just for saving some lines of code in the toolkit (and not even all of them) is an overly good idea. It's not just for 'saving some lines of code in the toolkit'. Color management would require significantly more code in the toolkit and would most likely be slower then if it is done in the compositing manager. I was just talking about communicate using subwindow id/profile tuples vs. communicate using toplevel window region/profile tuples. The former would save a bit of code in the toolkit, but would complicate compositing managers significantly; which is why I strongly prefer the latter. The compositing manager would never actually draw subwindows, just merely use them to identify regions. When using properties on the top level window, the toolkit would have to explicitly update those whenever the window is resized. But when using subwindows, the toolkit (at least gtk) wouldn't have to do anything special. In gtk, each widget that uses a subwindow resizes it when the top level window is resized. The compositing manager would just subscribe to ConfigureNotify events of the subwindows and be done. tom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gnome canvas doesnt work properly on GTK-DirectFB
Hi all Built a gnome canvas application on GTK-DirectFB(gtk+-2.10.14) and certain portions of the windows appear black , On clicking in the windows some of them appear white as expected. What could be the reason for such a behaviour on GTK-DirectFB backend.? Investigation has revealed the following: (please correct me if i'm wrong) - since cairo package is built w/0 X linkage , there is an issue with cairo_draw_with_xlib and hence the canvas is failing to render. -The gtk_widget_send_expose ( ) must be replaced with gdk_window_invalidate_region( ) in certain portions of the code. -Upgrading the cuurent cairo (orignal was 15.4) version didnt help. -Could it be a gtk d version issue ? Dont have a clear understanding in this regard , any inputs/cooments on the sited issue will be of great help. Thanks Reagards sv. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
