Thijs Koerselman

I wrote this opengl UI object using jit.pwindow, and I'm a little in the

dark about how to handle the redrawing the right way. With jsui, when you

move something like a window over it, it redraws itself automatically.

jit.pwindow doesn't do that. The only solution I know is to have a scheduler

or qmetro redraw the ui on a fixed interval, but that feels like a big waste

of resources, when the thing is just sitting there doing nothing.

Is this the way regular UI elements work, or is there another / better way?

Or maybe a way to know whether its visible or not?

I wrote this opengl UI object using jit.pwindow, and I'm a little in the
dark about how to handle the redrawing the right way. With jsui, when you
move something like a window over it, it redraws itself automatically.
jit.pwindow doesn't do that. The only solution I know is to have a scheduler
or qmetro redraw the ui on a fixed interval, but that feels like a big waste
of resources, when the thing is just sitting there doing nothing.

Is this the way regular UI elements work, or is there another / better way?
Or maybe a way to know whether its visible or not?

manual-ui-redrawing

use a doublebuffer? I think thats the solution?

On Aug 28, 2006, at 3:38 PM, Thijs Koerselman wrote:

> I wrote this opengl UI object using jit.pwindow, and I'm a little 

> in the dark about how to handle the redrawing the right way. With 

> jsui, when you move something like a window over it, it redraws 

> itself automatically. jit.pwindow doesn't do that. The only 

> solution I know is to have a scheduler or qmetro redraw the ui on a 

> fixed interval, but that feels like a big waste of resources, when 

> the thing is just sitting there doing nothing.

> Is this the way regular UI elements work, or is there another / 

> better way? Or maybe a way to know whether its visible or not?

> I wrote this opengl UI object using jit.pwindow, and I'm a little  
> in the dark about how to handle the redrawing the right way. With  
> jsui, when you move something like a window over it, it redraws  
> itself automatically. jit.pwindow doesn't do that. The only  
> solution I know is to have a scheduler or qmetro redraw the ui on a  
> fixed interval, but that feels like a big waste of resources, when  
> the thing is just sitting there doing nothing.
>
> Is this the way regular UI elements work, or is there another /  
> better way? Or maybe a way to know whether its visible or not?
>
> -thijs
>

> use a doublebuffer? I think thats the solution?

Actually, this is only one aspect of the potential solution. This 

will let you simply swap buffers to refresh to the screen with the 

swap message to jit.gl.render, rather than redering the entire scene 

with the bang method (equivalent to the drawclients, swap message 

sequence). However, the fundamental problem Thijs is pointing out is 

that jit.pwindow does not expose any way to know if the jit.pwindow 

visible region has been invalidated and needs to be swapped.

jit.pwindow works fine this way when it doesn't own an OpenGL 

context, with jitter matrices, as it knows when it has been 

invalidated and when to refresh, copying the RAM backing buffer to 

the screen (@onscreen 0). We can add something to expose this via 

jit.pwindow in the future, but for now, you'll need to use some other 

technique to work around this limitation.

Actually, this is only one aspect of the potential solution. This  
will let you simply swap buffers to refresh to the screen with the  
swap message to jit.gl.render, rather than redering the entire scene  
with the bang method (equivalent to the drawclients, swap message  
sequence). However, the fundamental problem Thijs is pointing out is  
that jit.pwindow does not expose any way to know if the jit.pwindow  
visible region has been invalidated and needs to be swapped.

jit.pwindow works fine this way when it doesn't own an OpenGL  
context, with jitter matrices, as it knows when it has been  
invalidated and when to refresh, copying the RAM backing buffer to  
the screen (@onscreen 0). We can add something to expose this via  
jit.pwindow in the future, but for now, you'll need to use some other  
technique to work around this limitation.

> On Aug 28, 2006, at 2:08 PM, vade wrote:

> > use a doublebuffer? I think thats the solution?

> Actually, this is only one aspect of the potential solution. This

> will let you simply swap buffers to refresh to the screen with the

> swap message to jit.gl.render, rather than redering the entire scene

> with the bang method (equivalent to the drawclients, swap message

I always assumed that you can only swap once, and if you do it twice you get

a blank buffer, but come to think of think of it.... as long as it's not

erased you can keep swapping. makes perfect sense:-)

jit.pwindow works fine this way when it doesn't own an OpenGL

> context, with jitter matrices, as it knows when it has been

> invalidated and when to refresh, copying the RAM backing buffer to

> the screen (@onscreen 0). We can add something to expose this via

> jit.pwindow in the future, but for now, you'll need to use some other

> technique to work around this limitation.

The only workaround I can think of is to render the ui only if it's the

front patcher window. That won't work for pluggo I suspect, but it will take

a while before I get to that anyway. I would certainly appreciate it if this

feature can be added in the future, because I plan on making a lot more UI

speaking of redrawing... I have a timeline walking across on top of

everything else. To prevent the ui from re-rendering, I cache the context to

a texture, and draw the texture on a plane with the timeline over it. Works

fine, but I have a feeling there is a better way. If so please enlighten me.

Something similar to copypixels in jsui maybe?

On 8/28/06, Joshua Kit Clayton  wrote:
>
>
> On Aug 28, 2006, at 2:08 PM, vade wrote:
>
> > use a doublebuffer? I think thats the solution?
>
> Actually, this is only one aspect of the potential solution. This
> will let you simply swap buffers to refresh to the screen with the
> swap message to jit.gl.render, rather than redering the entire scene
> with the bang method (equivalent to the drawclients, swap message
> sequence).

I always assumed that you can only swap once, and if you do it twice you get
a blank buffer, but come to think of think of it.... as long as it's not
erased you can keep swapping. makes perfect sense:-)

jit.pwindow works fine this way when it doesn't own an OpenGL
> context, with jitter matrices, as it knows when it has been
> invalidated and when to refresh, copying the RAM backing buffer to
> the screen (@onscreen 0). We can add something to expose this via
> jit.pwindow in the future, but for now, you'll need to use some other
> technique to work around this limitation.

The only workaround I can think of is to render the ui only if it's the
front patcher window. That won't work for pluggo I suspect, but it will take
a while before I get to that anyway. I would certainly appreciate it if this
feature can be added in the future, because I plan on making a lot more UI
stuff with jit.pwindow.

speaking of redrawing... I have a timeline walking across on top of
everything else. To prevent the ui from re-rendering, I cache the context to
a texture, and draw the texture on a plane with the timeline over it. Works
fine, but I have a feeling there is a better way. If so please enlighten me.
Something similar to copypixels in jsui maybe?

On Aug 28, 2006, at 3:42 PM, Thijs Koerselman wrote:

> speaking of redrawing... I have a timeline walking across on top of 

> everything else. To prevent the ui from re-rendering, I cache the 

> context to a texture, and draw the texture on a plane with the 

> timeline over it. Works fine, but I have a feeling there is a 

> better way. If so please enlighten me. Something similar to 

Rendering to a texture and re-using the texture is the best way to do 

this in Jitter. The copypixels method is only better in JSUI since it 

is in software. On the HW, the only way we expose you to cache GPU 

> speaking of redrawing... I have a timeline walking across on top of  
> everything else. To prevent the ui from re-rendering, I cache the  
> context to a texture, and draw the texture on a plane with the  
> timeline over it. Works fine, but I have a feeling there is a  
> better way. If so please enlighten me. Something similar to  
> copypixels in jsui maybe?

Rendering to a texture and re-using the texture is the best way to do  
this in Jitter. The copypixels method is only better in JSUI since it  
is in software. On the HW, the only way we expose you to cache GPU  
pixel resources is through textures.

> Rendering to a texture and re-using the texture is the best way to do

> this in Jitter. The copypixels method is only better in JSUI since it

> is in software. On the HW, the only way we expose you to cache GPU

ok that's fine, just checking. The swapping is working out great. I'm

updating only once every 500ms (in idle state) so there is no noticeable cpu

load yet. I still have to think about the timeline drawing but its looking

>
> Rendering to a texture and re-using the texture is the best way to do
> this in Jitter. The copypixels method is only better in JSUI since it
> is in software. On the HW, the only way we expose you to cache GPU
> pixel resources is through textures.

ok that's fine, just checking. The swapping is working out great. I'm
updating only once every 500ms (in idle state) so there is no noticeable cpu
load yet. I still have to think about the timeline drawing but its looking
good so far. Thanks a lot.

manual UI redrawing