I can take care of committing all the gtk patches along with the previous patch for gdk events which i already tested and seems to be ok. One question about the code inside
#ifndef NO_EXPERIMENTS ... #endif shall it be committed and activated, committed but not activated or not committed at all? sincerely Attilio Denis Oliver Kropp wrote: > Hi, > > here are a bunch of patches which improve the overall speed of GDK-DirectFB a > lot > and also contain a few fixes. In our special test case the load was reduced > by 70%, > speeding up tab switching 3.3 times! > > The patches should be applied in the following order (probably skipping the > two HACKs): > > window_flip_group.patch > no_background_pixmap_fix.patch > blit_after_cairo_fix.patch > rect_clip_fix.patch > rgb16_default.patch > HACK_no_clear.patch > fast_blend.patch > opt_clip_region_and_fill_rects.patch > no_state_resets.patch > opt_temp_region_etc.patch > opt_temp_region2.patch > HACK_no_clear_area.patch > > > Another patch is for Cairo: > > cairo_show_glyphs.patch > > > Each patch header has a description, here's an overview: > > - window_flip_group.patch > GDK-DIRECTFB: During update processing, don't flip immediately, but > accumulate a flipping region using the DirectFB > update manager and flush all Flip()s at the end of all painting. This results > in a UI update In One Go [tm]! > > > - no_background_pixmap_fix.patch > GDK-DIRECTFB: Fix setting of NULL pixmaps resulting in a GDK_NO_BG setting. > Probably GDK had an > API change at some point in time. > > > - blit_after_cairo_fix.patch > GDK-DIRECTFB: Fix wrong blitting flags being used by GDK after Cairo changed > the state. > > > - rect_clip_fix.patch > GDK-DIRECTFB: Fix clipping rectangle for filling rectangles after Cairo has > modified it. > > > - rgb16_default.patch > GDK-DIRECTFB: Use RGB16 format by default. > > > - HACK_no_clear.patch > GDK-DIRECTFB: Experimentally comment out the clear in > gdk_window_impl_directfb_begin_paint_region(). > > This speeds up the test app without visual impact, but it might harm other > (traditional?) apps. > > > - fast_blend.patch > GDK-DIRECTFB: Start with our own implementation of gdk_drawable_draw_pixbuf() > based on the original. > > First modifications are: > - No scratch image used, saving two copies. > - Replaced composite_565() implementation by an optimized version doing 32 > bit wise I/O. > > Clipping might need to be fixed. > > > - opt_clip_region_and_fill_rects.patch > GDK-DIRECTFB: Another small improvement by using FillRectangles() instead of > FillRectangle(). > > Avoid a temporary memory allocation in gdk_directfb_clip_region(). > > > - no_state_resets.patch > GDK-DIRECTFB: Don't set back states after drawing/blitting, just make sure > they're correct before being used. > > > - opt_temp_region_etc.patch > GDK-DIRECTFB: Introduce temp_region functions and avoid temporary memory > allocation in a lot of places. > > > - opt_temp_region2.patch > GDK-DIRECTFB: Changed remaining places where temp_region can be used. Added > caching of the clip region during painting. > > > - HACK_no_clear_area.patch > GDK-DIRECTFB: Experimentally comment out the clear in > _gdk_windowing_window_clear_area[_e] and don't invalidate in > show_window_internal(). > > This speeds up the test app without visual impact, but it might harm other > (traditional?) apps. > > > - cairo_show_glyphs.patch > CAIRO-DIRECTFB: Use DirectFB for show_glyphs() even if it is unaccelerated. > > The software fallback in DirectFB is well optimized. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > directfb-dev mailing list > [EMAIL PROTECTED] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
