[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] limit window constraints?




Charles, you're the man!

I can now fix the SpectrogramWindow. 

- when calling c.refresh it marks the Rect(200,0,200,200) (c.bounds) as needing refresh -> so every view intersecting this rect should be refreshed

why is this so? Can we not have overlapping UserViews where only one is refreshed?

cheers
thor


- the thing here is that in the source, for the bounds intersection method  (SCRectsDoIntersect):
Rect(200,0,200,200) DO INTERSECTS Rect(0,0,200,200) -> wich is v.bounds

(
as an example in sclang:
c.bounds.intersects(v.bounds) reports true
(the implementation is the same in the source so you can test to see)
)

so v.drawFunc gets executed even if you specified that you need to refresh the c.bounds region...

BUT

in OS X all drawing calls in v.drawFunc should not be executed and flushed because the context was already clipped to Rect(200,0,200,200)...
so that's half bug :)
you should not have a performance penalty...

to test this just execute this while you are running your Task

c.bounds_(Rect(201,0,200,200)); // offset by 1

--> you should only see "C is drawing" now on the log window because now 

c.bounds.intersects(v.bounds) === false

(as i said the implementation of  SCRectsDoIntersect in sc source is the same so...)

bug ? :)

best,
charles


Le 17 mars 09 à 14:59, thor a écrit :

Hi Chad

Ok, say I have the strings in a drawFunc of a UserView. 
It seems to me that it always updates when the window refreshes.

Check the code below. Only c is refreshed, but the whole window is
refreshed, and thus the "monkey" view will always be refreshed as well.

Or is there a trick here? I can't see it.

(
w = GUI.window.new;
v = GUI.userView.new(w, Rect(0,0, 200, 200)).background_(Color.yellow).resize_(4);
v.drawFunc = {
"V is Drawing".postln;
      4.squared.do({ arg i; GUI.pen.stringAtPoint("monkey",
              (v.bounds.width/4 * (i % 4))@(v.bounds.height/4 * (i div: 4))
      ) });
    // v.drawingEnabled_(false);
     //v.clearOnRefresh_(true);
};

c = GUI.userView.new(w, Rect(200,0, 200, 200)).background_(Color.red).resize_(5);
c.drawFunc = {
"C is Drawing".postln;
Pen.color = Color.black;
      4.squared.do({ arg i; GUI.pen.stringAtPoint("TEST".scramble,
              (v.bounds.width/4 * (i % 4))@(v.bounds.height/4 * (i div: 4))
      ) });
};

w.front;

Task({
inf.do({
{c.refresh}.defer;
0.5.wait;
});
}).start;
)

On 17 Mar 2009, at 12:20, Chad Kirby wrote:

Thor, in the example, the strings are not drawn 24 times/sec. Rather,
drawFunc is called only when the userView is refreshed. In your case,
you'd probably want to attach the Pen strings to a view that is not
refreshed at a constant rate... or you could wait for the onResize
implementation. That works too 8^)

(
w = GUI.window.new;
v = GUI.userView.new(w, w.view.bounds).background_(Color.yellow).resize_(5);
v.drawFunc = {
"I am drawing".postln;
      8.squared.do({ arg i; GUI.pen.stringAtPoint("monkey",
              (v.bounds.width/8 * (i % 8))@(v.bounds.height/8 * (i div: 8))
      ) });
};
w.front;
bench({v.drawFunc}).asFraction
)

-ck

On Mon, Mar 16, 2009 at 11:21 AM, thor <thor.magnusson@xxxxxxxxx> wrote:

Hi Chad

I had completely forgotten about GUI.pen.string.

It's just the idea of drawing strings that should be static 24 times per
second that I don't like.

I think I'll wait with this as Charles has already implemented onResize for
Window.

cheers


On 16 Mar 2009, at 15:53, Chad Kirby wrote:

Thor,

I didn't create my own font--I'm just using Pen's string methods:
(
w = GUI.window.new;
v = GUI.userView.new(w,
w.view.bounds).background_(Color.yellow).resize_(5);
v.drawFunc = {
       8.squared.do({ arg i; GUI.pen.stringAtPoint("monkey",
               (v.bounds.width/8 * (i % 8))@(v.bounds.height/8 * (i div:
8))
       ) });
};
w.front;
bench({v.drawFunc}).asFraction
)

This admittedly simple example takes around 1/500,000 of a second to
run on my macbook. It seems like a similar approach could work for the
Spectrogram window.

Chad

On Mon, Mar 16, 2009 at 2:47 AM, thor <th.list@xxxxxxxxx> wrote:

On 15 Mar 2009, at 23:52, Chad Kirby wrote:

As far as I know, the only way to re-scale the text on the left in the
Spectrogram window would be to draw the text with Pen and
algorithmically lay it out depending on the window bounds. That's what
I do in my app.

Which app is that?
But have you benchmarked how much processing it takes to draw
that? In Spectrogram I'm drawing 24 frames per second and I'd rather
not draw text with Pen. (the thought of it makes me dizzy anyway : )
did you create your own font?)


My little resize control doesn't address anything like
that. It's just a one-trick pony--lets you set limits on the size of
the window--for certain windows.

I know. I was just pointing out that there is a need for looking at this
in
Window.


cheers
thor





Chad

On Sun, Mar 15, 2009 at 1:58 PM, thor <th.list@xxxxxxxxx> wrote:

On 15 Mar 2009, at 20:35, Chad Kirby wrote:

As for the drawHook, it's just there to draw the diagonal lines in the
control. You could do it without the drawHook--just remove the Pen
stuff and set the background of the SCUserView to a color that
contrasts with the window background so the user can see to click in
the corner.

I wasn't talking about the drawHook in your code. I was pointing out
that
if you want to rearrange a window on its resize, you can't do it
properly
unless
putting things into a drawHook, thus my suggestion of .onResize({})

If you check the SpectrogramWindow Quark, you'll see what I mean. The
frequencies
on the left (StaticText) cannot be rearranged on resize. Or at least I
can't
see the
way to do that.



_______________________________________________
sc-users mailing list

info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/



_______________________________________________
sc-users mailing list

info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/