I think may be the width and height of picutures you draw are odd number . ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, July 14, 2006 6:00 PM Subject: directfb-dev Digest, Vol 18, Issue 12
> Send directfb-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of directfb-dev digest..." > > > Today's Topics: > > 1. How to Create SubSurfaces (Erick Galassi) > 2. Re: Nasty issue with subsurfaces (Denis Oliver Kropp) > 3. Re: Nasty issue with subsurfaces (Mike Emmel) > 4. Directfb Backend (Mike Emmel) > 5. Re: Directfb Backend (Attilio Fiandrotti) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 13 Jul 2006 10:07:00 -0300 > From: "Erick Galassi" <[EMAIL PROTECTED]> > Subject: [directfb-dev] How to Create SubSurfaces > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi All, > > I?m facing a trouble while trying to create surfaces to show image files > on screen. My main issue is: if a create a surface for each image that is > going to be shown on the screen, after a certain amount of surfaces created > I get a "out of video memory" error. On the other hand, if I do not create > and store surfaces for each image the performance of my application will be > very slow , considering that I?ll need to RenderTo the imageprovider > everytime that I want to print on the screen. > > So, I thought about using SubSurfaces, once that they may not use any > extra memory , but somehow I?m not being able to create and flip the > subsurface created. Following is part of my code: > > { primary surfaces is already created and named as : primary } > { I create a new surface , with the screen size , to be the main surface > for images subsurfaces, named as : workarea } > { directfb is already initialize and named as : dfb } > { I?m calling this new subsurface as imageSurface } > > DFBSurfaceDescription workareaDSC; > workareaDSC.flags workareaDSC.caps workareaDSC.width > workareaDSC.height > dfb->CreateSurface(dfb,&workareaDSC,&workarea); > > DFBSurfaceDescription imageDSC; > imageDSC.flags imageDSC.caps > DFBRectangle imageRECT; > {x , y , w and h are set with the image (top,left,width,height) > positions} > > dfb->CreateImageProvider(dfb,imagepathname,&imageProvider); > imageProvider->GetSurfaceDescription(imageProvider,&imageDSC); > workarea->GetSubSurface(workarea,&imageRECT,&imageSurface); > imageProvider->RenderTo(imageProvider,imageSurface,NULL); > > workarea->Blit(workarea,imageSurface,&imageRECT,imageLeft,imageTop); > workarea->Flip(workarea,NULL,DSFLIP_BLIT); > > After running this code I get the following error: > > RenderTo: Not Supported. > > I?ve tried to render direct into the primary surface , however I still > get an error that says: > > Blit-> Invalid area present > > Please, excuse me if this is not the property way to ask such a > question, but It is my first time posting here. I also want more information > about how to colabotare with the DirectFB project, The API and Tutorial are > very uptodate and I really want help to improve the support over this > technology. > > Thank you all in advance, > Erick Galassi > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://mail.directfb.org/pipermail/directfb-dev/attachments/20060713/e452e6a2/attachment.html > > > ------------------------------ > > Message: 2 > Date: Thu, 13 Jul 2006 16:06:08 +0200 > From: Denis Oliver Kropp <[EMAIL PROTECTED]> > Subject: Re: [directfb-dev] Nasty issue with subsurfaces > To: Mike Emmel <[EMAIL PROTECTED]> > Cc: directfb-dev <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Mike Emmel wrote: > > I added a call to GetVisibleRect which gives basically the visible > > region of the main surface in the subsurface coordinates seems to work > > but I'm thinking when you lock the surface > > one of the params should be a rectangle that is the visible rect ? > > If someone's using sub surfaces, that one should be aware of the offset > and query the visible region - if needed - itself. > > What about having something like Read() and Write() in IDirectFBSurface > to read/write blocks of data from/to the buffer with automatic locking, > offsets, clipping and *maybe* format conversion? > > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > > > > ------------------------------ > > Message: 3 > Date: Thu, 13 Jul 2006 11:07:29 -0700 > From: "Mike Emmel" <[EMAIL PROTECTED]> > Subject: Re: [directfb-dev] Nasty issue with subsurfaces > To: "Denis Oliver Kropp" <[EMAIL PROTECTED]> > Cc: directfb-dev <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 7/13/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > Mike Emmel wrote: > > > I added a call to GetVisibleRect which gives basically the visible > > > region of the main surface in the subsurface coordinates seems to work > > > but I'm thinking when you lock the surface > > > one of the params should be a rectangle that is the visible rect ? > > > > If someone's using sub surfaces, that one should be aware of the offset > > and query the visible region - if needed - itself. > > > > What about having something like Read() and Write() in IDirectFBSurface > > to read/write blocks of data from/to the buffer with automatic locking, > > offsets, clipping and *maybe* format conversion? > > Hmm yeah something like that maybe in a lot of ways subsurfaces are > not a good idea in the > sense that a subsurface is not a real surface. > > Let me get some other stuff checked in then I'm going to add get/set > Prop on the core object > and send the patch to the list. > > After that I'm convinced that we need to create a region based > abstraction layer on top of core surfaces > these regions can share the real surface with there parent or not. > > Windows should be built on top of that and created by the wm not in the core. > > Probably this requires a real design to show what I'm talking about. > Anyway the point is windows become abstract we have now have > collections of regions on top. The window api stays but is really just > a wrapper for a region of a surface. > Event handling except to designate the region under a mouse event is no longer > handled in core at all but in the WM. > > So the addition would be a region can be buffered or use its parent > its up to it. > Do you see a problem with that ? > > Agian its really similar to what you already do in unique but we flip > the region stuff into the core and the window/wm stuff out and I'm > adding optional buffering or sharing. > > Mike > > > > -- > > Best regards, > > Denis Oliver Kropp > > > > .------------------------------------------. > > | DirectFB - Hardware accelerated graphics | > > | http://www.directfb.org/ | > > "------------------------------------------" > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 13 Jul 2006 17:22:01 -0700 > From: "Mike Emmel" <[EMAIL PROTECTED]> > Subject: [directfb-dev] Directfb Backend > To: directfb-dev <[email protected]>, "Gtk+ Developers" > <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I just checked in a redo of the directfb cairo backend to remove > secondary buffers. > This is in Cairo git it also fixed subsurface issues. > > Next the gdk directfb backend now implements paintable so the > additional pixma buffering is removed. > > There are a lot of basic changes in this checkin and a good chance > that some things are broken. But its the last major work I plan to do > on the core drawing since now its basically correct and we can focus > on remaining bugs. > > Sorry it took so long to get out. > Please test esp with the debian installer. > > Now I can look at debian installer bugs agian ! > > > Mike > > > > ------------------------------ > > Message: 5 > Date: Fri, 14 Jul 2006 09:56:50 +0200 > From: Attilio Fiandrotti <[EMAIL PROTECTED]> > Subject: Re: [directfb-dev] Directfb Backend > To: Mike Emmel <[EMAIL PROTECTED]>, directfb-dev > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi > > I just checked out everything (DFB, cairo, GTK+) from CVS and > compilation of cairo-directfb-surface.c failed as follows > > cairo-directfb-surface.c: In function ?_directfb_acquire_surface?: > cairo-directfb-surface.c:351: error: ?cairo_directfb_surface_t? has no > member named ?buffer? > > which was easily fixed with > > --- a/src/cairo-directfb-surface.c > +++ b/src/cairo-directfb-surface.c > @@ -349,7 +349,7 @@ _directfb_acquire_surface (cairo_directf > surface->dfbsurface->GetSize > (surface->dfbsurface,&source_rect.w, &source_rect.h); > } > D_DEBUG_AT (Cairo_DirectFB, "%s buffer for surface.\n", > - surface->buffer ? "Reallocating" : "Allocating"); > + buffer ? "Reallocating" : "Allocating"); > cairo_format = directfb_to_cairo_format(DSPF_ARGB); > buffer = _directfb_buffer_surface_create > (surface->dfb,DSPF_ARGB,source_rect.w,source_rect.h); > if (!buffer) > > the real problem is that GTK apps still crash: below is a debug session > of gtk-demo (very same problem for other GTK apps too). > > ciao > > Attilio > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1487206720 (LWP 17740)] > 0x001d0258 in ?? () > (gdb) bt > #0 0x001d0258 in ?? () > #1 0xa77ed626 in _cairo_directfb_surface_fill_rectangles > (abstract_surface=0x82805e0, op=CAIRO_OPERATOR_OVER, > color=0xafdcb5a0, rects=0x827eee0, n_rects=9) at > cairo-directfb-surface.c:927 > #2 0xa77d3627 in _cairo_surface_fill_rectangles (surface=0x82805e0, > op=CAIRO_OPERATOR_OVER, color=0xafdcb5a0, > rects=0x827eee0, num_rects=9) at cairo-surface.c:1161 > #3 0xa77d3840 in _cairo_surface_fill_region (surface=0x82805e0, > op=CAIRO_OPERATOR_OVER, color=0xafdcb5a0, region=0x8272498) > at cairo-surface.c:1116 > #4 0xa77d636e in _clip_and_composite_trapezoids (src=<value optimized > out>, op=<value optimized out>, dst=0x82805e0, > traps=0xafdcb4f4, clip=0x827ee1c, > antialias=CAIRO_ANTIALIAS_DEFAULT) at cairo-surface-fallback.c:597 > #5 0xa77d6500 in _cairo_surface_fallback_fill (surface=0x82805e0, > op=CAIRO_OPERATOR_OVER, source=0xafdcb55c, > path=0x8231ec8, fill_rule=CAIRO_FILL_RULE_WINDING, > tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT) > at cairo-surface-fallback.c:832 > #6 0xa77d3f83 in _cairo_surface_fill (surface=0x82805e0, > op=CAIRO_OPERATOR_OVER, source=0xafdcb614, path=0x8231ec8, > fill_rule=CAIRO_FILL_RULE_WINDING, tolerance=0.10000000000000001, > antialias=CAIRO_ANTIALIAS_DEFAULT) > at cairo-surface.c:1321 > #7 0xa77c89b4 in _cairo_gstate_fill (gstate=0x827ed98, path=0x8231ec8) > at cairo-gstate.c:974 > #8 0xa77c4109 in *INT_cairo_fill_preserve (cr=0x8231ec0) at cairo.c:1884 > #9 0xa77c4132 in cairo_fill (cr=0x8231ec0) at cairo.c:1862 > #10 0xa7ec0bff in gdk_window_clear_backing_rect (window=0x80c84b0, x=0, > y=0, width=600, height=400) at gdkwindow.c:1877 > #11 0xa7ebeacd in IA__gdk_window_begin_paint_region (window=0x80c84b0, > region=0x81e9b00) at gdkwindow.c:1016 > #12 0xa7c081fc in IA__gtk_main_do_event (event=0xafdcb7d4) at gtkmain.c:1378 > #13 0xa7ec1fe9 in gdk_window_process_updates_internal (window=0x80c84b0) > at gdkwindow.c:2324 > #14 0xa7ec2123 in IA__gdk_window_process_all_updates () at gdkwindow.c:2387 > #15 0xa7b4bc9b in gtk_container_idle_sizer (data=0x0) at gtkcontainer.c:1113 > #16 0xa78aaaa1 in g_idle_dispatch (source=0x81e5928, callback=0x82762f8, > user_data=0x0) at gmain.c:3924 > #17 0xa78ac821 in IA__g_main_context_dispatch (context=0x80d7f50) at > gmain.c:2043 > #18 0xa78af896 in g_main_context_iterate (context=0x80d7f50, block=1, > dispatch=1, self=0x80d80d8) at gmain.c:2675 > #19 0xa78afc57 in IA__g_main_loop_run (loop=0x823b220) at gmain.c:2879 > ---Type <return> to continue, or q <return> to quit--- > #20 0xa7c07901 in IA__gtk_main () at gtkmain.c:1000 > #21 0x0806618d in main (argc=1, argv=0xafdcbae4) at main.c:924 > > > > ------------------------------ > > _______________________________________________ > directfb-dev mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > End of directfb-dev Digest, Vol 18, Issue 12 > ******************************************** _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
