manual UI redrawing

Aug 28, 2006 at 7:38pm

manual UI redrawing

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

#27360
Aug 28, 2006 at 9:08pm

use a doublebuffer? I think thats the solution?

v a d e //

http://www.vade.info
abstrakt.vade.info

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?
>
> -thijs
>

#82705
Aug 28, 2006 at 9:24pm

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). 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.

-Joshua

#82706
Aug 28, 2006 at 10:42pm

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?

cheers, -thijs

#82707
Aug 29, 2006 at 12:01am

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
> 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.

-Joshua

#82708
Aug 29, 2006 at 12:37am

On 8/29/06, Joshua Kit Clayton wrote:

>
> 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.

-thijs

#82709

You must be logged in to reply to this topic.