dest_dim in dest_changed()

Feb 1, 2007 at 10:43pm

dest_dim in dest_changed()

not sure if this is a bug or not, but should the dest_dim attribute
be the current destination dimensions in a call to dest_changed()
(triggered from a window resize), or should it be the previous
dimensions?

jit_gl_foo_dest_changed(t_jit_gl_foo *x) {
long dest_dim[2];
jit_attr_getlong_array(x, gensym(“dest_dim”), 2, dest_dim);
post(“destination dimensions: %dx%d”, dest_dim[0], dest_dim[1], 0);

GLint viewport[4];
glGetIntegerv(GL_VIEWPORT, viewport);
post(“viewport: %d %d %d %d”, viewport[0], viewport[1], viewport[2],
viewport[3]);
}

prints out

destination dimensions: 1×1
viewport: 0 0 320 240

when I start the renderer. I can use glGet* for now, but was
wondering about the validity of other attributes within dest_changed.

thanks,

r.

#30075
Feb 1, 2007 at 11:14pm

On Feb 1, 2007, at 2:43 PM, ritchie argue wrote:

> not sure if this is a bug or not, but should the dest_dim attribute
> be the current destination dimensions in a call to dest_changed()
> (triggered from a window resize), or should it be the previous
> dimensions?

It will be the previous size. This is only set on updateclients or draw.

> when I start the renderer. I can use glGet* for now, but was
> wondering about the validity of other attributes within dest_changed.

Which ones out of curiosity? You shouldn’t really “do” anything in
dest_changed aside from marking a flag that you need to update in
your next draw call. This is the only thing we use it for in our
object set.

-Joshua

#95260
Feb 1, 2007 at 11:58pm

On 07-02-01, at 1514, Joshua Kit Clayton wrote:
>
> Which ones out of curiosity? You shouldn’t really “do” anything in
> dest_changed aside from marking a flag that you need to update in
> your next draw call. This is the only thing we use it for in our
> object set.
>
ah, that makes sense now. I was working from jit.gl.videoplane, and
the texture was being configured from dest_changed(), so I assumed I
could do more there. I’ll try to re-factor some things into recalc().

out of curiosity, should dest_changed() be called when switching
between windowed and fullscreen? if not, is there a way to be
notified of this switch? I’d like to know when the aspect ratio of
the output window changes, without having to poll the viewport from
draw().

best,
r.

#95261
Feb 2, 2007 at 2:01am

On Feb 1, 2007, at 3:58 PM, ritchie argue wrote:

> out of curiosity, should dest_changed() be called when switching
> between windowed and fullscreen?

Offhand, I can’t remember (easy to find out empirically).

> if not, is there a way to be notified of this switch? I’d like to
> know when the aspect ratio of the output window changes, without
> having to poll the viewport from draw().

You can subscribe as a client to the destination window, just like a
JitterListener in JS/Java. Check out the object registration/
notification chapter in the Jitter SDK.

-Joshua

#95262
Feb 2, 2007 at 3:42am

On 07-02-01, at 1801, Joshua Kit Clayton wrote:
>
>> out of curiosity, should dest_changed() be called when switching
>> between windowed and fullscreen?
>
> Offhand, I can’t remember (easy to find out empirically).
>
what I meant to say is that dest_changed() was _not being called when
switching between windowed and fullscreen. I thought it would as it
does when the window is resized via dragging, but I guess not.

>> if not, is there a way to be notified of this switch? I’d like to
>> know when the aspect ratio of the output window changes, without
>> having to poll the viewport from draw().
>
> You can subscribe as a client to the destination window, just like
> a JitterListener in JS/Java. Check out the object registration/
> notification chapter in the Jitter SDK.
>
thanks. so I listened for some messages, and this is what I see when
I print out the server, message, and data. does the data that comes
with attr_modified indicate _which attribute was modified somehow?

// going to fullscreen
notify: server=sync message=block
notify: server=sync message=modified
notify: server=sync message=unblock
notify: server=sync message=attr_modified
data: 5b66630
// returning from fullscreen
notify: server=sync message=block
notify: server=sync message=modified
notify: server=sync message=unblock
notify: server=sync message=attr_modified
data: 5b66630

I tried looking at it with the debugger, but am finding it a little
opaque.

thanks,

r.

#95263
Feb 2, 2007 at 6:12pm

On Feb 1, 2007, at 7:42 PM, ritchie argue wrote:

> thanks. so I listened for some messages, and this is what I see
> when I print out the server, message, and data. does the data that
> comes with attr_modified indicate _which attribute was modified
> somehow?
>
> notify: server=sync message=attr_modified
> data: 5b66630

Yes, the data pointer is a t_object * of the attribute which has been
modified. Sorry that this isn’t better documented, since not that
many outside developers have needed access to it yet.

t_symbol *attrname = jit_object_method(data,_jit_sym_getname);

Hope this helps.

-Joshua

#95264
Feb 2, 2007 at 8:46pm

On 07-02-02, at 1012, Joshua Kit Clayton wrote:
>
> Yes, the data pointer is a t_object * of the attribute which has
> been modified. Sorry that this isn’t better documented, since not
> that many outside developers have needed access to it yet.
>
> t_symbol *attrname = jit_object_method(data,_jit_sym_getname);
>
> Hope this helps.
>
yep, that’s perfect thanks. as long as you don’t mind documenting
this in realtime on the list, I’ll figure it all out eventually =)

r.

#95265

You must be logged in to reply to this topic.