Lidj wrote: > Niels Roest wrote: > >> (cut some stuff for readability) >> I assume you mean that you can run Windows on your ARM system, where >> your performance is as you expect? And the rest of the system is >> configured the same (with double buffering, screen resolution, screen >> format, etcetera) ? Otherwise you risk comparing apples to pears. >> >> > > Sorry, windows system means in XP / KDE /GNOME , because current graphic > card can run > well on this system. > But now I think the loading on driving graphic card run 30fps should all > be taken by system. > Windows system should spare some resource on this, so that graphic card > can support 30 fps. > > > > Niels Roest wrote: > >>>>> >>>>> >>>> if I remove memcpy, the process of moving data to videosurface will >>>> skip. >>>> Therefore it will do nothing on this test program, also output >>>> nothing. >>>> >>>> >>>> >> That's not necessarily true. >> The Flip() will copy data from the back to the front buffer, if you >> configured it like that. >> You can try front-only to see if this speed things up. >> >> > > Sorry I think I need to study hard on this, I don't know how to use > front-only. > now use double buffer > <====== > videosurce->Lock (videosurce, DSLF_WRITE, &data, &pitch); > memcpy(data, src+YUVFRAME_Pitch*y, YUVFRAME_Pitch); > videosurce->Unlock (videosurce); > videosurface->Flip(videosurface, NULL, DSFLIP_NONE); > ======> > > You can either put "frontonly" it in your directfbrc, or put it in the description of SetConfig() for the layer you wish to (re)configure.
> > > Niels Roest wrote: > >>>> But I don't know use what function to replace memcpy. >>>> memcpy is the faster way to copy data. >>>> >>>> >>>> >> ..apart from DMA. >> if your graphics accelerator and directfb support it, you can copy the >> data first to a off-screen surface, and then use that to Blit() it to >> the surface of your display layer. Of course you need to make sure that >> your DMA engine can access the off-screen surface, so maybe you need to >> put it in video memory. >> >> >> >> Is this flow as you mentioned ? >> <===capture from df_andi.c==== >> dfb->CreateImageProvider( dfb, DATADIR"/wood_andi.jpg",&provider ) >> provider->GetSurfaceDescription (provider, &dsc); >> dfb->CreateSurface( dfb, &dsc, &background ); >> (provider->RenderTo( provider, background, NULL ); >> provider->Release( provider ); >> >> then >> primary->Blit( primary, background, NULL, 0, 0 ); >> ======> >> Now I got crash on this, I need to study more on this ><" >> >> I cannot say if this is the right flow. It highly depends on your system configuration, the hardware that you use, and the load on your system (other programs running) which way is best. Something you have to decide yourself.. You can build with debugging on, like "DEBUG=yes make" and then run with debugging, so put "debug" in your directfbrc. Or you can print the error codes, normally DirectFB functions must return DFB_OK. > also > CreateImageProvider ( > IDirectFB * thiz, > const char * filename, > IDirectFBImageProvider ** ret_interface > ); > > is CreateImageProvider only can use <const char * filename>, > because my resource data is coming from network, so it only have array > format -> char temp[i] > Can I us char temp[i] to instead of fileneme? > > Yeah, should be good. > Thanks for help. > > Lidj. > > > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
