Forums > Dev

dest_dim in dest_changed()

February 1, 2007 | 10:43 pm

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.


February 1, 2007 | 11:14 pm

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


February 1, 2007 | 11:58 pm

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.


February 2, 2007 | 2:01 am

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


February 2, 2007 | 3:42 am

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.


February 2, 2007 | 6:12 pm

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


February 2, 2007 | 8:46 pm

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.


Viewing 7 posts - 1 through 7 (of 7 total)