Jacek Rudnicki(deleted)
|
gf_draw_blit2() - problem with bigger surface size
|
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)
|
Re: gf_draw_blit2() - problem with bigger surface size
|
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 ?
|
|
|
Mike Gorchak
|
Re: gf_draw_blit2() - problem with bigger surface size
|
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
|
RE: gf_draw_blit2() - problem with bigger surface size
|
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)
|
Re: RE: gf_draw_blit2() - problem with bigger surface size
|
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)
|
Re: RE: gf_draw_blit2() - problem with bigger surface size
|
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
|
RE: RE: gf_draw_blit2() - problem with bigger surface size
|
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
|
|
|
|