Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Graphics/Discussion/Advanced Graphics/gf_draw_blit2() - problem with bigger surface size/List of Posts
Forum Topic - gf_draw_blit2() - problem with bigger surface size: (7 Items)
   
Update
Jacek Rudnicki(deleted)
08/19/2012 8:52 AM
post94942
gf_draw_blit2() - problem with bigger surface size   
In my application I had to call the gf_draw_blit2() very often.

When size of the image is 320x240:
gf_draw_blit2 (context, img_surf, NULL, 0, 0, 319, 239, 0, 0); 
then everything works fine.

When size of the image is 640x480
gf_draw_blit2 (context, img_surf, NULL, 0, 0, 639, 479, 0, 0);
several consecutive lines in the window are black (not rendered at all).

Does mean that hardware is too slow ?
Or maybe I'm doing something wrong ?

I'm testing against the devg-i830.so driver (Device Id: 0x2582).
Jacek Rudnicki(deleted)
08/19/2012 1:27 PM
post94943
Re: gf_draw_blit2() - problem with bigger surface size   
I have attached picture that shows a black area.
Rest from image lines are displayed properly.

Has anybody idea whay these black lines are visible and how can I get rid of them ?
Attachment: Image image_640.JPG 99.07 KB
Mike Gorchak
09/05/2012 1:47 AM
post95374
Re: gf_draw_blit2() - problem with bigger surface size   
> Does mean that hardware is too slow ?

Maybe, do you using plain blit2 or with additional context flags enabled, like chroma, etc?

> Or maybe I'm doing something wrong ?

I've seen similar behavior when forgot to use flush at the end of picture rendering in case if you have mixed 
environment, like software+hardware operations on the same surface. Two or more consecutive blit2()s without flush() can
 be optimized by hardware, you will get the last blit2() result. 

There are few possible issues:
1) You are not using flush() for blit2() operation. And blit2() is the only function which is called. Hardware will take
 video memory content for blitting in asynchronous way. For example, 1/1000 of sec is a delay between command to 
graphics controller has been issued and real blit2() execution in hardware. But in next 1/100000 sec you will get 3-4 
optimized blit2() operations, while content of video memory was changed partially.
2) In the same time your application can use some graphics operations which are implemented in software. For example, 
output of some text and picture to the same surface. This is a race condition between software text rendering and 
hardware blit2(), so some strange visible artifacts could be observed. It depends on a GPU caching policy. So correct 
operations sequence will be blit2() -> flush() -> put_text("FPS: %d").
3) You are updating your video frame content asynchronously comparing to blit2() operation. For example, there is 
possible such situation: two tasks are not synchronized, one is filling data which it obtains from camera and second one
 is doing blit2() + flush(). Due to asynchronous nature of GPU, it can execute blit2() in the same time when changing of
 video frame content is in process. In such case double buffering for managing video stream will be a solution.
Derek Leach
09/05/2012 8:40 AM
post95386
RE: gf_draw_blit2() - problem with bigger surface size   
Someone here fixed something similar in another unrelated piece of software, where the gf_context_t was not inited 
properly, and we were getting similar behaviour.

-----Original Message-----
From: Mike Gorchak [mailto:community-noreply@qnx.com] 
Sent: September-05-12 1:48 AM
To: advanced-graphics
Subject: Re: gf_draw_blit2() - problem with bigger surface size

> Does mean that hardware is too slow ?

Maybe, do you using plain blit2 or with additional context flags enabled, like chroma, etc?

> Or maybe I'm doing something wrong ?

I've seen similar behavior when forgot to use flush at the end of picture rendering in case if you have mixed 
environment, like software+hardware operations on the same surface. Two or more consecutive blit2()s without flush() can
 be optimized by hardware, you will get the last blit2() result. 

There are few possible issues:
1) You are not using flush() for blit2() operation. And blit2() is the only function which is called. Hardware will take
 video memory content for blitting in asynchronous way. For example, 1/1000 of sec is a delay between command to 
graphics controller has been issued and real blit2() execution in hardware. But in next 1/100000 sec you will get 3-4 
optimized blit2() operations, while content of video memory was changed partially.
2) In the same time your application can use some graphics operations which are implemented in software. For example, 
output of some text and picture to the same surface. This is a race condition between software text rendering and 
hardware blit2(), so some strange visible artifacts could be observed. It depends on a GPU caching policy. So correct 
operations sequence will be blit2() -> flush() -> put_text("FPS: %d").
3) You are updating your video frame content asynchronously comparing to blit2() operation. For example, there is 
possible such situation: two tasks are not synchronized, one is filling data which it obtains from camera and second one
 is doing blit2() + flush(). Due to asynchronous nature of GPU, it can execute blit2() in the same time when changing of
 video frame content is in process. In such case double buffering for managing video stream will be a solution.




_______________________________________________

Advanced Graphics
http://community.qnx.com/sf/go/post95374
To cancel your subscription to this discussion, please e-mail advanced-graphics-unsubscribe@community.qnx.com
Jacek Rudnicki(deleted)
09/06/2012 5:09 PM
post95423
Re: RE: gf_draw_blit2() - problem with bigger surface size   
I believe that the gf_context_t is inited properly.

Here is a part of code responsible for drawing:
   gf_draw_begin (context);
   gf_draw_blit2 (context, img_surf, NULL, 0, 0, 639, 479, 0, 0);
   gf_draw_flush (context);
   gf_draw_end (context); 
nothing specific but fails.

When I do a blit2() operation more often but on smaller area then everything is ok:
  gf_draw_begin (context);
  gf_draw_blit2 (context, img_surf, NULL, 0, 0, BUFLEN*2-1, 0, 0, index*2);
  gf_draw_blit2 (context, img_surf, NULL, 0, 0, BUFLEN*2-1, 0, 0, index*2+1);	 	
  gf_draw_flush (context);
  gf_draw_end (context); 
BUFLEN is defined as 320.

In both examples img_suf is connected with the same 640x480 target area.
Mike Gorchak(deleted)
09/07/2012 4:15 AM
post95426
Re: RE: gf_draw_blit2() - problem with bigger surface size   
> I believe that the gf_context_t is inited properly.
> 
> Here is a part of code responsible for drawing:
>    gf_draw_begin (context);
>    gf_draw_blit2 (context, img_surf, NULL, 0, 0, 639, 479, 0, 0);
>    gf_draw_flush (context);
>    gf_draw_end (context); 
> nothing specific but fails.> 
> When I do a blit2() operation more often but on smaller area then everything 
> is ok:
>   gf_draw_begin (context);
>   gf_draw_blit2 (context, img_surf, NULL, 0, 0, BUFLEN*2-1, 0, 0, index*2);
>   gf_draw_blit2 (context, img_surf, NULL, 0, 0, BUFLEN*2-1, 0, 0, index*2+1);	
>  	
>   gf_draw_flush (context);
>   gf_draw_end (context); 
> BUFLEN is defined as 320.
> 
> In both examples img_suf is connected with the same 640x480 target area.

Hi, 

What will happen in case of using static picture in img_surf, like previous captured frame?

Thanks.
Derek Leach
09/07/2012 8:37 AM
post95433
RE: RE: gf_draw_blit2() - problem with bigger surface size   
True, but is there any way that another code path could have modified the context?

-----Original Message-----
From: Jacek Rudnicki [mailto:community-noreply@qnx.com] 
Sent: September-06-12 5:09 PM
To: advanced-graphics
Subject: Re: RE: gf_draw_blit2() - problem with bigger surface size

I believe that the gf_context_t is inited properly.

Here is a part of code responsible for drawing:
   gf_draw_begin (context);
   gf_draw_blit2 (context, img_surf, NULL, 0, 0, 639, 479, 0, 0);
   gf_draw_flush (context);
   gf_draw_end (context); 
nothing specific but fails.

When I do a blit2() operation more often but on smaller area then everything is ok:
  gf_draw_begin (context);
  gf_draw_blit2 (context, img_surf, NULL, 0, 0, BUFLEN*2-1, 0, 0, index*2);
  gf_draw_blit2 (context, img_surf, NULL, 0, 0, BUFLEN*2-1, 0, 0, index*2+1);	 	
  gf_draw_flush (context);
  gf_draw_end (context); 
BUFLEN is defined as 320.

In both examples img_suf is connected with the same 640x480 target area.




_______________________________________________

Advanced Graphics
http://community.qnx.com/sf/go/post95423
To cancel your subscription to this discussion, please e-mail advanced-graphics-unsubscribe@community.qnx.com

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems