nanogui: Thread: nanox double buffering

Hi all,
I'm a bit baffled by a problem I have with double buffering.
I borrowed some code from Jordan's patch for double buffering and 
those who use it before may have some ideas. I'll appreciate it.

fliping the buffer essentially does what the code below shows.
To me it looks like when the buffer is flipped, the order is
"flip then draw" instead of "draw then flip". I say this because the screen
shows what looks like a background drawing flicker.

I don't see how this could happen but surely I'm missing something.
Does anyone know where this occurs and how to change it?

void
GdPanScreen(PSD psd, int xoffset, int yoffset) {

    if (!psd->PanScreen) return;
    if ((psd->xvisible != psd->xvirtres)) {
        /* Bound it */
        if (xoffset < 0) xoffset = 0;
        if (xoffset + psd->xvisible > psd->xvirtres)
            xoffset = psd->xvirtres - psd->xvisible;
    }
    else
        xoffset = 0;

    if ((psd->yvisible != psd->yvirtres)) {

        /* Bound it */
        if (yoffset < 0) yoffset = 0;
        if (yoffset + psd->yvisible > psd->yvirtres)
            yoffset = psd->yvirtres - psd->yvisible;
    }
    else
        yoffset = 0;

    if (xoffset != psd->xoffset || yoffset != psd->yoffset) {
        psd->yoffset = yoffset;
        psd->xoffset = xoffset;

        fb_var.xoffset = xoffset;
        fb_var.yoffset = yoffset;
        ioctl(fb, FBIOPAN_DISPLAY, &fb_var);

     }

Thank you.

Hi All,
Just an addition, alternatively, is there a mechanism where I can blit a
changes region or the difference from one buffer to another?

Thank you.

> -----Original Message-----
> From: ####@####.####
> Sent: Wed, 6 Jun 2007 08:22:39 -0800
> To: ####@####.####
> Subject: [nanogui] nanox double buffering
> 
> Hi all,
> I'm a bit baffled by a problem I have with double buffering.
> I borrowed some code from Jordan's patch for double buffering and
> those who use it before may have some ideas. I'll appreciate it.
> 
> fliping the buffer essentially does what the code below shows.
> To me it looks like when the buffer is flipped, the order is
> "flip then draw" instead of "draw then flip". I say this because the
> screen
> shows what looks like a background drawing flicker.
> 
> I don't see how this could happen but surely I'm missing something.
> Does anyone know where this occurs and how to change it?
> 
> void
> GdPanScreen(PSD psd, int xoffset, int yoffset) {
> 
>     if (!psd->PanScreen) return;
>     if ((psd->xvisible != psd->xvirtres)) {
>         /* Bound it */
>         if (xoffset < 0) xoffset = 0;
>         if (xoffset + psd->xvisible > psd->xvirtres)
>             xoffset = psd->xvirtres - psd->xvisible;
>     }
>     else
>         xoffset = 0;
> 
>     if ((psd->yvisible != psd->yvirtres)) {
> 
>         /* Bound it */
>         if (yoffset < 0) yoffset = 0;
>         if (yoffset + psd->yvisible > psd->yvirtres)
>             yoffset = psd->yvirtres - psd->yvisible;
>     }
>     else
>         yoffset = 0;
> 
>     if (xoffset != psd->xoffset || yoffset != psd->yoffset) {
>         psd->yoffset = yoffset;
>         psd->xoffset = xoffset;
> 
>         fb_var.xoffset = xoffset;
>         fb_var.yoffset = yoffset;
>         ioctl(fb, FBIOPAN_DISPLAY, &fb_var);
> 
>      }
> 
> Thank you.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

On Wed, Jun 06, 2007 at 09:07:41AM -0800, Junior wrote:
> >         ioctl(fb, FBIOPAN_DISPLAY, &fb_var);
>
> Just an addition, alternatively, is there a mechanism where I can blit
> a changes region or the difference from one buffer to another?

I think your problems are with the implementation of the
FBIOPAN_DISPLAY, which is beyond the realm of microwindows.  are things
less flickery if you use GrCopyArea()?

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

>> Just an addition, alternatively, is there a mechanism where I can blit
>> a changes region or the difference from one buffer to another?
> 
> I think your problems are with the implementation of the
> FBIOPAN_DISPLAY, which is beyond the realm of microwindows.  are things
> less flickery if you use GrCopyArea()?

Actually, no. That's why I went to double buffering.
I still have this problem and this a bit unusual.
I believe there is a bug somewhere in this package and I've been trying to 
track it down. So far I'm not there yet.
The "flicker" only happends when I use the GrFillRect call. This should be done
on my offscreen pixmap and my traces through the main aread show that it does,
but for some reason, which I struggling to explain, using this function call
causes these lines on the screen.

I first tried this with manipulating a pixmap then do a GrCopyArea, but I see it.
I do double buffering and it's much less aparent but it's still there. If I take away
the nanox package and write directly to my fb0 device, it's not there.
I'm trying to understand the package API internal as I pursue this.
If anyone have any ideas I would love to hear them.

Thanks,
--Jr.

____________________________________________________________
FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop!
Check it out at http://www.inbox.com/marineaquarium

On Tue, Jun 12, 2007 at 10:57:03AM -0800, Junior wrote:
> > I think your problems are with the implementation of the
> > FBIOPAN_DISPLAY, which is beyond the realm of microwindows.  are
> > things less flickery if you use GrCopyArea()?
> 
> Actually, no. That's why I went to double buffering.
> I still have this problem and this a bit unusual.
> I believe there is a bug somewhere in this package and I've been
> trying to track it down. So far I'm not there yet.
>
> The "flicker" only happends when I use the GrFillRect call. This
> should be done on my offscreen pixmap and my traces through the main
> aread show that it does, but for some reason, which I struggling to
> explain, using this function call causes these lines on the screen.

let me see if I understand correctly.

an _offscreen_ pixmap is created with GrNewPixmap().

calling GrFillRect on that pixmap causes undesired effects _onscreen_?

> I first tried this with manipulating a pixmap then do a GrCopyArea,
> but I see it.  I do double buffering and it's much less aparent but
> it's still there. If I take away the nanox package and write directly
> to my fb0 device, it's not there.  I'm trying to understand the
> package API internal as I pursue this.  If anyone have any ideas I
> would love to hear them.

I'm still not clear on your call sequence to nano-X.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

> let me see if I understand correctly.
> 
> an _offscreen_ pixmap is created with GrNewPixmap().
> 
> calling GrFillRect on that pixmap causes undesired effects _onscreen_?
> 
>> I first tried this with manipulating a pixmap then do a GrCopyArea,
>> but I see it.  I do double buffering and it's much less aparent but
>> it's still there. If I take away the nanox package and write directly
>> to my fb0 device, it's not there.  I'm trying to understand the
>> package API internal as I pursue this.  If anyone have any ideas I
>> would love to hear them.
> 
> I'm still not clear on your call sequence to nano-X.
> 

I create offscreen pixmap with GrNewPixmap();
I do GrFillRect()
      GrText()
      GrCopyArea() 
in that order and I see undesired horiz lines.

I further do a a double buffer:
      GrFillRect()
      GrText()
      GrCopyArea() to inactive buffer
      GrFlip buffer()
and it did not make a difference.

If on the other hand I do:
      GrText()   without background color (effect writing over what there , look ugly)
      GrCopyArea()
It looks very clean.

Is there any potential problem with this sequence?

Thanks
Jr.

> I do GrFillRect()
      GrText()
      GrCopyArea() 
in that order and I see undesired horiz lines.

If we're going to get down-and-dirty, then replace
the GrFillRect call above with a for() loop
drawing horizontal lines, or pixels even.  Then,
see if the flicker is still there.  If it is, then I would
say it might be a hardware issue related to just drawing
that color in the screen location, rather than anything
to do with filling the rectangular area.

I'm assuming that the screen isn't in fact repainted
the same way when GrFillRect isn't used, so we're
not yet really debugging GrFillRect vs another method
of filling that rectangular space.

Regards,

Greg

>> I do GrFillRect()
>       GrText()
>       GrCopyArea()
> in that order and I see undesired horiz lines.
> 
> If we're going to get down-and-dirty, then replace
> the GrFillRect call above with a for() loop
> drawing horizontal lines, or pixels even.  Then,
> see if the flicker is still there.  If it is, then I would
> say it might be a hardware issue related to just drawing
> that color in the screen location, rather than anything
> to do with filling the rectangular area.
> 
> I'm assuming that the screen isn't in fact repainted
> the same way when GrFillRect isn't used, so we're
> not yet really debugging GrFillRect vs another method
> of filling that rectangular space.

I haven't tried your suggestion yet but I stumble on something as I went 
through some ideas I have.
I'm dying to explain this one.
Below is part of my event loop, the part that actually updates the screen:


int i = 0;
void handle_event(void)
{
    if((OT_SFLAG & OT_SCRN_REWR) !=0)
    {
            GrFlush();
            printf("Flip\n");
if(i < 1){
    i++;
            printf("cols: %d, rows: %d, active:%d\n",tscrn_info.cols,tscrn_info.rows,dbuff->active);
            printf("viscols: %d, visrows: %d\n",tscrn_info.viscols,tscrn_info.visrows);
            GrFlipBuffers(dbuff);
            GrSetGCGraphicsExposure(scrn_gc, GR_FALSE);
            printf("Copy\n");
            GrCopyArea(dbuff->buf[!dbuff->active], scrn_gc, 0, 0, tscrn_info.viscols,
                        tscrn_info.visrows, dbuff->buf[dbuff->active] ,0, 0,MWROP_COPY);
            GrSetGCGraphicsExposure(scrn_gc, GR_TRUE);
            main_window = dbuff->buf[!dbuff->active];
         }

...
}

With this configuration, the screen is perfectly still, updating as expected.
Without the "if" statement there is undesirable flashes on the screen that seem to
occur during the GrCopyArea. Atleast I didn't seen the horiz lines during the copy.
Nonetheless, if I'm writing to the main_window which is not active, 
Why is the screen being updated? That's whay I'm dying to explain.

Any senario is welcome.

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

I'm not sure what is happening yet.  You need to GrFlush()
after your CopyArea call though.  You didn't mention
the GCGraphicsExposure changes, I'm not sure why
you're changing it, and that's likely where your problems
are.  Make sure your window has background erase
turned off.

Greg


int i = 0;
void handle_event(void)
{
    if((OT_SFLAG & OT_SCRN_REWR) !=0)
    {
            GrFlush();
            printf("Flip\n");
if(i < 1){
    i++;
            printf("cols: %d, rows: %d, 
active:%d\n",tscrn_info.cols,tscrn_info.rows,dbuff->active);
            printf("viscols: %d, visrows: 
%d\n",tscrn_info.viscols,tscrn_info.visrows);
            GrFlipBuffers(dbuff);
            GrSetGCGraphicsExposure(scrn_gc, GR_FALSE);
            printf("Copy\n");
            GrCopyArea(dbuff->buf[!dbuff->active], scrn_gc, 0, 0, 
tscrn_info.viscols,
                        tscrn_info.visrows, dbuff->buf[dbuff->active] ,0, 
0,MWROP_COPY);
            GrSetGCGraphicsExposure(scrn_gc, GR_TRUE);
            main_window = dbuff->buf[!dbuff->active];
         }

...
}

With this configuration, the screen is perfectly still, updating as 
expected.
Without the "if" statement there is undesirable flashes on the screen that 
seem to
occur during the GrCopyArea. Atleast I didn't seen the horiz lines during 
the copy.
Nonetheless, if I'm writing to the main_window which is not active,
Why is the screen being updated? That's whay I'm dying to explain.

Any senario is welcome.

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

> I'm not sure what is happening yet.  You need to GrFlush()
> after your CopyArea call though.  You didn't mention
> the GCGraphicsExposure changes, I'm not sure why
> you're changing it, and that's likely where your problems
> are.  Make sure your window has background erase
> turned off.

If I don't turn expose off, it'll flicker when I do the CopyArea.
How do I turn off background erase? I don't see that flag in the
either the GC or WINDOW structs.

Jr.


> int i = 0;
> void handle_event(void)
> {
>     if((OT_SFLAG & OT_SCRN_REWR) !=0)
>     {
>             GrFlush();
>             printf("Flip\n");
> if(i < 1){
>     i++;
>             printf("cols: %d, rows: %d,
> active:%d\n",tscrn_info.cols,tscrn_info.rows,dbuff->active);
>             printf("viscols: %d, visrows:
> %d\n",tscrn_info.viscols,tscrn_info.visrows);
>             GrFlipBuffers(dbuff);
>             GrSetGCGraphicsExposure(scrn_gc, GR_FALSE);
>             printf("Copy\n");
>             GrCopyArea(dbuff->buf[!dbuff->active], scrn_gc, 0, 0,
> tscrn_info.viscols,
>                         tscrn_info.visrows, dbuff->buf[dbuff->active] ,0,
> 0,MWROP_COPY);
>             GrSetGCGraphicsExposure(scrn_gc, GR_TRUE);
>             main_window = dbuff->buf[!dbuff->active];
>          }
> 
> ...
> }
> 
> With this configuration, the screen is perfectly still, updating as
> expected.
> Without the "if" statement there is undesirable flashes on the screen
> that
> seem to
> occur during the GrCopyArea. Atleast I didn't seen the horiz lines during
> the copy.
> Nonetheless, if I'm writing to the main_window which is not active,
> Why is the screen being updated? That's whay I'm dying to explain.
> 
> Any senario is welcome.

____________________________________________________________
GET FREE 5GB EMAIL - Check out spam free email with many cool features!
Visit http://www.inbox.com/email to find out more!