nanogui: Thread: Screen update methods

Hi,
I'm wondering if there are any other methods that will update the main active window.

I've been using an offscreen pixmap and then do a copy and I recently ran into a problem
that does not occur when I use QT.

I'm considering the posibility that the frame being copied to the framebuffer might be partially drawn and
some how produces flucturations in pixel intensity on a horizontal line.
I haven't been able to explain these lines and I'm trying to understand how nano-X actually update the active buffer.

Can someone who understands this better offer any help?

Thanks,
--Jr.

____________________________________________________________
GET FREE SMILEYS FOR YOUR IM & EMAIL - Learn more at http://www.inbox.com/smileys
Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and most webmails

Junior napsal(a):
> Hi,
> I'm wondering if there are any other methods that will update the main active window.
>
> I've been using an offscreen pixmap and then do a copy and I recently ran into a problem
> that does not occur when I use QT.
>
> I'm considering the posibility that the frame being copied to the framebuffer might be partially drawn and
> some how produces flucturations in pixel intensity on a horizontal line.
> I haven't been able to explain these lines and I'm trying to understand how nano-X actually update the active buffer.
>
> Can someone who understands this better offer any help?
>   
No, but if it's any consolation, I've seen the same effect myself.  I 
always thought it was an artifact of my hardware - as in my case it 
seems to occur in vertical lines.

--Yan

> -----Original Message-----
> From: ####@####.####
> Sent: Fri, 25 May 2007 07:49:00 -0700
> To: ####@####.#### ####@####.####
> Subject: Re: [nanogui] Screen update methods
> 
> Junior napsal(a):
>> Hi,
>> I'm wondering if there are any other methods that will update the main
>> active window.
>> 
>> I've been using an offscreen pixmap and then do a copy and I recently
>> ran into a problem
>> that does not occur when I use QT.
>> 
>> I'm considering the posibility that the frame being copied to the
>> framebuffer might be partially drawn and
>> some how produces flucturations in pixel intensity on a horizontal line.
>> I haven't been able to explain these lines and I'm trying to understand
>> how nano-X actually update the active buffer.
>> 
>> Can someone who understands this better offer any help?
>> 
> No, but if it's any consolation, I've seen the same effect myself.  I
> always thought it was an artifact of my hardware - as in my case it
> seems to occur in vertical lines.
> 
> --Yan

What did you do? Did you ever found a work around?

--Jr. 

Junior wrote:
>> -----Original Message-----
>> From: ####@####.####
>> Sent: Fri, 25 May 2007 07:49:00 -0700
>> To: ####@####.#### ####@####.####
>> Subject: Re: [nanogui] Screen update methods
>>
>> Junior napsal(a):
>>     
>>> Hi,
>>> I'm wondering if there are any other methods that will update the main
>>> active window.
>>>
>>> I've been using an offscreen pixmap and then do a copy and I recently
>>> ran into a problem
>>> that does not occur when I use QT.
>>>
>>> I'm considering the posibility that the frame being copied to the
>>> framebuffer might be partially drawn and
>>> some how produces flucturations in pixel intensity on a horizontal line.
>>> I haven't been able to explain these lines and I'm trying to understand
>>> how nano-X actually update the active buffer.
>>>
>>> Can someone who understands this better offer any help?
>>>
>>>       
>> No, but if it's any consolation, I've seen the same effect myself.  I
>> always thought it was an artifact of my hardware - as in my case it
>> seems to occur in vertical lines.
>>
>> --Yan
>>     
>
> What did you do? Did you ever found a work around?
>   

It's not critical to our use, so I've been ignoring it.  No complaints 
so far.  Sorry I can't be of more help.  :-(

--Yan

> Junior wrote:
>>> -----Original Message-----
>>> From: ####@####.####
>>> Sent: Fri, 25 May 2007 07:49:00 -0700
>>> To: ####@####.#### ####@####.####
>>> Subject: Re: [nanogui] Screen update methods
>>> 
>>> Junior napsal(a):
>>> 
>>>> Hi,
>>>> I'm wondering if there are any other methods that will update the main
>>>> active window.
>>>> 
>>>> I've been using an offscreen pixmap and then do a copy and I recently
>>>> ran into a problem
>>>> that does not occur when I use QT.
>>>> 
>>>> I'm considering the posibility that the frame being copied to the
>>>> framebuffer might be partially drawn and
>>>> some how produces flucturations in pixel intensity on a horizontal
>>>> line.
>>>> I haven't been able to explain these lines and I'm trying to
>>>> understand
>>>> how nano-X actually update the active buffer.
>>>> 
>>>> Can someone who understands this better offer any help?
>>>> 
>>>> 
>>> No, but if it's any consolation, I've seen the same effect myself.  I
>>> always thought it was an artifact of my hardware - as in my case it
>>> seems to occur in vertical lines.
>>> 
>>> --Yan
>>> 
>> 
>> What did you do? Did you ever found a work around?
>> 
> 
> It's not critical to our use, so I've been ignoring it.  No complaints
> so far.  Sorry I can't be of more help.  :-(
> 

Thanks though.

I've done a bit of digging and I realize I'm not using the Blit finction in the linear16 driver.
For every pixel I seem to be actually drawing individual pixel instead of copying a chunk of memory.
Way back, I rember Gregg saying GrCopy actually does the screen blit. Unless I miss something, that doesn't seem to 
be the case here.
I understood that the idea of using an offscreen pixmap is such that I can blit the entire screen and not draw
individual pixels. Is this not true?

--Jr.

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

On Fri, May 25, 2007 at 07:36:11AM -0800, Junior wrote:
> I understood that the idea of using an offscreen pixmap is such that I
> can blit the entire screen and not draw individual pixels. Is this not
> true?

this is true, but only if you have hardware that supports an actual blit
operation.  the best you can get without hardware acceleration is an
optimized block copy, which again, depending on your hardware, may end
up copying pixel-by-pixel.

your problem may be something as simple as needing vertical retrace
synchronization before copying to the screen.

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

> On Fri, May 25, 2007 at 07:36:11AM -0800, Junior wrote:
>> I understood that the idea of using an offscreen pixmap is such that I
>> can blit the entire screen and not draw individual pixels. Is this not
>> true?
> 
> this is true, but only if you have hardware that supports an actual blit
> operation.  the best you can get without hardware acceleration is an
> optimized block copy, which again, depending on your hardware, may end
> up copying pixel-by-pixel.
> 
> your problem may be something as simple as needing vertical retrace
> synchronization before copying to the screen.

Thanks Aaron,
That actually crossed my mind and I was looking into how to implement it,
especially with a memory mapped framebuffer with no sync being used.
This seem to be a framebuffer driver addition than an application, yes?

I've done some tracing and what seem to be really killing me is this linear16_drawhorizline
function. That makes things worse and I haven't figured out when it's called and buy how.
It seems that drawing background color calles it but I'm not sure.

Thanks
--Jr.

On Fri, May 25, 2007 at 01:58:53PM -0800, Junior wrote:
> [vertical retrace] actually crossed my mind and I was looking into how
> to implement it, especially with a memory mapped framebuffer with no
> sync being used.  This seem to be a framebuffer driver addition than
> an application, yes?

it depends on the memory protection on your target.  you may not be able
to directly peek at the video hardware from your application in
userland, in which case it would have to be done in the (kernel)
framebuffer driver.

> I've done some tracing and what seem to be really killing me is this
> linear16_drawhorizline function. That makes things worse and I haven't
> figured out when it's called and buy how.  It seems that drawing
> background color calles it but I'm not sure.

background color calls down to rectangle draw which calls down to
horizontal line.  you might want to start a new driver based on
fblin16.c and do some optimizations.

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

> -----Original Message-----
> From: ####@####.####
> Sent: Fri, 25 May 2007 17:16:41 -0700
> To: ####@####.####
> Subject: Re: [nanogui] Re: Screen update methods
> 
> On Fri, May 25, 2007 at 01:58:53PM -0800, Junior wrote:
>> [vertical retrace] actually crossed my mind and I was looking into how
>> to implement it, especially with a memory mapped framebuffer with no
>> sync being used.  This seem to be a framebuffer driver addition than
>> an application, yes?
> 
> it depends on the memory protection on your target.  you may not be able
> to directly peek at the video hardware from your application in
> userland, in which case it would have to be done in the (kernel)
> framebuffer driver.
> 
>> I've done some tracing and what seem to be really killing me is this
>> linear16_drawhorizline function. That makes things worse and I haven't
>> figured out when it's called and buy how.  It seems that drawing
>> background color calles it but I'm not sure.
> 
> background color calls down to rectangle draw which calls down to
> horizontal line.  you might want to start a new driver based on
> fblin16.c and do some optimizations.

What's really bothering me is why are the lowlevel driver called to write any data
to the framebuffer when it's being called to draw them on a pixmap. I seem to be missing
something here and I'm hoping someone could tell me what that is.
I only expect the blit function to be called when I explicitly copy data from the offscreen
pixmap to the active window. Is this not true? Any drawing I've done I've done on a pixmap
so I can do one block copy to the framebuffer.

--Jr.

> What's really bothering me is why are the lowlevel driver called to write 
> any data
to the framebuffer when it's being called to draw them on a pixmap. I seem 
to be missing something here and I'm hoping someone could tell me what that 
is.

In terms of drawing, the framebuffer and a pixmap are
*exactly* the same, just a different start memory address.
You're thinking that a framebuffer is something different or
special, when its just a block of memory to draw into,
just like a pixmap is.

The nano-X low level drivers all draw into a memory block,
and have no idea what the "block" really is.  And they don't
need to, since the drawing requires exactly the same code.

> I only expect the blit function to be called when I explicitly copy data 
> from the offscreen pixmap to the active window. Is this not true?

There is no such thing as an "active window".  There are only
draw rectangle memory locations with a clipping set.  The
draw locations can be the address of the actual framebuffer,
or any allocated pixmap, of course.

When drawing pixel-by-pixel, or line-by-line, the driver-
level drawpixel or drawline (horz or vert) routines are
called.  Rectangle fills currently use repeat horz drawline.
When copying a bitmap or memory, the blit routine is called.
There are not multiple options (routines) to determine when
drawing, instead set driver entrypoint(s) are called to
effect the required drawing.

> Any drawing I've done I've done on a pixmap
so I can do one block copy to the framebuffer.

Yes.  Unless you originally filled the pixmap
from another image, low-level pixel/line routines were
called to draw the pixmap, then the blit driver routine
was used to copy it (to the framebuffer or another
pixmap, they're just memory addresses).

Hope this helps.

Regards,

Greg