flicker-free "bouncing ball" example

Is a flicker-free "bouncing ball"-type 2-D example available somewhere? I'm
new to wxPython. Of course I could have done it with Visual (VPython) as a 3-D
exercise.

G Kalman wrote:

Is a flicker-free "bouncing ball"-type 2-D example available somewhere? I'm new to wxPython. Of course I could have done it with Visual (VPython) as a 3-D exercise.

It's not a bouncing ball, but this is a good example: http://wiki.wxpython.org/BubblesToy

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

G Kalman wrote:

Is a flicker-free "bouncing ball"-type 2-D example available somewhere? I'm new to wxPython. Of course I could have done it with Visual (VPython) as a 3-D exercise.

Not fliker-free, but it contains a bouncing ball.
  http://mientki.ruhosting.nl/data_www/pylab_works/pw_bricks_2d_scene.html
and here is even a small demo video
  http://stef.mientki.googlepages.com/2d_simulation.html
It's part of a large package, which I'm preparing for a first release, expected this month.

cheers,
Stfe

···

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

That's a cool demo! But I noticed that it's using a buffered DC even on OS X, which is a waste of CPU cycles since windows on OS X are double-buffered by the system.

So, I tried updating it thusly: in on_paint I changed it to AutoBufferedPaintDC, and (just for testing) I changed update_drawing to:

     def update_drawing(self):
         #dc = wx.BufferedDC(wx.ClientDC(self), self._buffer)
         dc = wx.ClientDC(self)
         dc.Clear()
  ...

This does seem to perform faster, but there's a problem: nothing is actually erased. The bubbles and X's just accumulate. But the docs say that dc.Clear should clear the drawing context to the background color. Any idea why that's not happening? What should I have done instead?

Thanks,
- Joe

···

On Oct 31, 2008, at 7:41 PM, Robin Dunn wrote:

It's not a bouncing ball, but this is a good example: http://wiki.wxpython.org/BubblesToy

Joe Strout wrote:

That's a cool demo! But I noticed that it's using a buffered DC even on OS X, which is a waste of CPU cycles since windows on OS X are double-buffered by the system.

yeah, I've just lived with that in my code so far -- part of the reason is that often I want that buffer for other reasons too -- like saving the image to a file, etc.

So, I tried updating it thusly: in on_paint I changed it to AutoBufferedPaintDC,

Thanks, I need to look at that some day.

and (just for testing) I changed update_drawing to:

    def update_drawing(self):
        #dc = wx.BufferedDC(wx.ClientDC(self), self._buffer)
        dc = wx.ClientDC(self)
        dc.Clear()
    ...

This does seem to perform faster, but there's a problem: nothing is actually erased. The bubbles and X's just accumulate. But the docs say that dc.Clear should clear the drawing context to the background color. Any idea why that's not happening?

There are issues with OS-X and drawing things "RIGHT NOW!". For instance, I think that if you make clientDC calls within a loop inside an event handler, it doesn't actually do the drawing until the handler is finished. It seems going from the buffer to the screen is handled by OS-X, and only between events.

What should I have done instead?

I think the "official" recommendation now is to not use clientDCs, but rather, do all your drawing in a PaintDC, and call Refresh() and Update() to force the Paint when you need to.

That lets the system decide exactly when to draw, which is supposed to be a better way to go.

However, I have found that it can't really keep up if you do need to draw RIGHT NOW, like during mouse move events, for instance.

We've been struggling with this with FloatCannvas2, and I don't think we've found a solution that works on all three platforms yet :frowning:

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

This does seem to perform faster, but there's a problem: nothing is actually erased. The bubbles and X's just accumulate. But the docs say that dc.Clear should clear the drawing context to the background color. Any idea why that's not happening?

There are issues with OS-X and drawing things "RIGHT NOW!". For instance, I think that if you make clientDC calls within a loop inside an event handler, it doesn't actually do the drawing until the handler is finished. It seems going from the buffer to the screen is handled by OS-X, and only between events.

That's all true (and is usually a Good Thing), but it's not what's going on here. I see the bubbles move; they're just not getting erased.

What should I have done instead?

I think the "official" recommendation now is to not use clientDCs, but rather, do all your drawing in a PaintDC, and call Refresh() and Update() to force the Paint when you need to.

That lets the system decide exactly when to draw, which is supposed to be a better way to go.

However, I have found that it can't really keep up if you do need to draw RIGHT NOW, like during mouse move events, for instance.

All true (and familiar to me from other environments). But it still doesn't explain why dc.Clear failed to clear the context. I could probably just paint a big white square instead of erasing, but I hate not understanding why something doesn't seem to be doing what it should. I'm also not going to be quick to assume it's a bug in wxWidgets or wxPython -- more likely there's some key step I've missed.

Best,
- Joe

···

On Nov 3, 2008, at 1:04 PM, Christopher Barker wrote:

Joe Strout wrote:

That's all true (and is usually a Good Thing), but it's not what's going on here. I see the bubbles move; they're just not getting erased.

One more idea -- I think Clear() pains the entire DC with the background brush. wxMac has better support for alpha in DCs than the other platforms -- might you be painting the DC with a transparent brush?

Did you call:

DC.SetBackground()

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Stef Mientki wrote:

Not fliker-free, but it contains a bouncing ball.
http://mientki.ruhosting.nl/data_www/pylab_works/pw_bricks_2d_scene.html
and here is even a small demo video
http://stef.mientki.googlepages.com/2d_simulation.html

quite cool!

Have you considered FloatCanvas? It's designed exactly for that kind of thing, and might solve the flicker problem for you to.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Christopher Barker wrote:

Joe Strout wrote:

That's all true (and is usually a Good Thing), but it's not what's going on here. I see the bubbles move; they're just not getting erased.

One more idea -- I think Clear() pains the entire DC with the background brush. wxMac has better support for alpha in DCs than the other platforms -- might you be painting the DC with a transparent brush?

The DC Clear method on Mac starts with this if statement:

     if (m_backgroundBrush.Ok() && m_backgroundBrush.GetStyle() != wxTRANSPARENT)
     {
         ...
     }

So if there is no background brush set or if it's the transparent brush, then the Clear() is essentially a NOP.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

hi Chris,

Christopher Barker wrote:

Stef Mientki wrote:

Not fliker-free, but it contains a bouncing ball.
http://mientki.ruhosting.nl/data_www/pylab_works/pw_bricks_2d_scene.html

and here is even a small demo video
http://stef.mientki.googlepages.com/2d_simulation.html

quite cool!

Have you considered FloatCanvas?

yes, and if I remember well we've discussed that before, maybe in some other setting.
What I initially needed, was a modified ogl, to make LabView like schematics.
As ogl and floatcanvas were much too difficult (for me, I'm not a programmer) to modify,
I got hold of OGL-like, just about 10% of the code of OGL and
much more understandable and appropriate to my needs.

Having a library that you can understand and thus control,
is sometimes much more important than having a perfect library that you can't control.

On the other hand, the 2D-scene I showed is just a docking place for ANY 2D library,
the code in the editor on the left controls the whole 2D scene,
so it would be nice to fit floatcanvas too,
just give me little piece of code that does soemthing similar, and I'll show how easy it fits into.
I've just finished my tests to dock VPython instead of the 2D-scene,
and it works !
I can't show the results yet, because my google project seems to be blocked for uploading :frowning:

cheers,
Stef

···

It's designed exactly for that kind of thing, and might solve the flicker problem for you to.

-Chris

Stef Mientki wrote:

Christopher Barker wrote:

Have you considered FloatCanvas?

yes, and if I remember well we've discussed that before, maybe in some other setting.
What I initially needed, was a modified ogl, to make LabView like schematics.

well, while FloatCanvas could help with that, it's not really what it was made for.

I got hold of OGL-like,

Which I think is just what you needed for that.

Having a library that you can understand and thus control,
is sometimes much more important than having a perfect library that you can't control.

well, yes and no. Often I think that we are so focused on getting SOMETHING done, the we don't want to take the time to learn a new tool, when, in fact, that time would be well spent.

On the other hand, the 2D-scene I showed is just a docking place for ANY 2D library,
the code in the editor on the left controls the whole 2D scene,
so it would be nice to fit floatcanvas too,
just give me little piece of code that does soemthing similar, and I'll show how easy it fits into.

Enclosed.

I brought this up again, because that kind of thing is exactly what FloatCanvas is made for -- giving a visual representation of some kind of data.

You can see that the drawing part of the demo I've enclosed is trivial. (so is the physics, but I didn't do that well!)

One note: I discovered a bug in the FloatCanvas Circle object when I wrote this, so the ball shifts a bit if you use the version built into wxPython. It has been fixed in SVN.

-Chris

BouncingBall.py (3.82 KB)

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

On the other hand, the 2D-scene I showed is just a docking place for ANY 2D library,
the code in the editor on the left controls the whole 2D scene,
so it would be nice to fit floatcanvas too,
just give me little piece of code that does soemthing similar, and I'll show how easy it fits into.

Enclosed.

great Chris,
I'll integrate it and make a demo of it, but ...
I doesn't run at my place :frowning:

        self.Ball = Canvas.AddObject( Ball( (5, 52), (1,1) ) )
        print type(self.Ball), self.Ball

using installed version: 0.9.18
<type 'bool'> True

Do I have an (too) old version of Floatcanvas.
If so, can you provide me a new one,
because I can't update wxPython at the moment,
because the newer versions of wxPython crashes almost all of my programs,
and I'm too busy to debug that problem.

cheers,
Stef

Stef Mientki wrote:

I doesn't run at my place :frowning:

       self.Ball = Canvas.AddObject( Ball( (5, 52), (1,1) ) )
       print type(self.Ball), self.Ball

using installed version: 0.9.18
<type 'bool'> True

Do I have an (too) old version of Floatcanvas.

could be -- I thought AddObject() always returned the object, but who knows? This should work:

         # add the ball:
         self.Ball = Ball( (5, 52), (1,1) )
         Canvas.AddObject( self.Ball )

If not, then you can get the latest as part of the entire wx SVN repository, or by itself with this url:

http://svn.wxwidgets.org/svn/wx/wxPython/3rdParty/FloatCanvas/

You can download it with this command:

svn co http://svn.wxwidgets.org/svn/wx/wxPython/3rdParty/FloatCanvas/ FloatCanvas

or the equivalent in your GUI SVN client of choice. If you can't use svn, please send a note to the mailing list, and we'll try to send you an archive of the code.

You can also browse the code with the viewvc interface:

http://svn.wxwidgets.org/viewvc/wx/wxPython/3rdParty/FloatCanvas/

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

hi Chris,
here the rest of the story.

Christopher Barker wrote:

Stef Mientki wrote:

Christopher Barker wrote:

Have you considered FloatCanvas?

yes, and if I remember well we've discussed that before, maybe in some other setting.
What I initially needed, was a modified ogl, to make LabView like schematics.

well, while FloatCanvas could help with that, it's not really what it was made for.

I got hold of OGL-like,

Which I think is just what you needed for that.

And interesting to know why I decided not to use OGL plain, which is an integral part of wxPython :wink:

Having a library that you can understand and thus control,
is sometimes much more important than having a perfect library that you can't control.

well, yes and no. Often I think that we are so focused on getting SOMETHING done, the we don't want to take the time to learn a new tool, when, in fact, that time would be well spent.

ok Yes and No.
Let me start that I always have weird ideas, which are not general accepted.
First of all, I don't accept limitations of software, that what the user wants, he should get, and I will guide him in the right direction.
This may sound obvious, but isn't in my opinion. 30 Years after we're using software in a normal world, almost all programs ask if I want to save my changesif I close the program. (Don't tell me that you don't want to save your changes in more than 10% of the cases).

So here is the evolution I made through in wxPython.
For my first large application I needed:
1- graphical schematic editor, that could draw blocks and connect them
2- a plot library to plot amplitude - time signals
3- a 2D (3D) animation for physics processes

Looking what wxPython offered (mainly observed from the wxPython demo):
A- ogl, a graphical schematic editor, sounds good :wink:
B- MatPlotLib, a copy of the plot library from MatLab
C- FloatCanvas, forgive I misjudged it by that time, a graffiti editor :wink:

Of course I would like to do all my 3 needs with just 1 library, but looking at the above, that seems to be impossible.

1. for the Graphical Schematic Editor, OGL seems to be the choice. But as I said the user had some wishes, he needed connection nodes. I also aksed help on this forum, but no one really seems to use it and looking into the code, I concluded this was way too high for me and so the risk of not realizing my goal was to high. Luckily I found OGL-like, written by Erik Lechak, who had exactly the same reasoning as me ;-). OGL-like was only 10% of the code of OGL-like, with more functionality in my direction.
So my personal conclusion: drop OGL in wxPython and include OGL-like.

2. for the plotting of amplitude-time curves, MatPlotLib seemed to be answer. But knowing how clumsy Matplot plots, I didn't have much faith in MatPlotLib :wink: In doing some exercises with MatPlotLib, having limiting examples, not understanding the dual interface to MatPlotLib, looking into the code, there was only conclusion possible, don't use it! I searched for another graphical library, but couldn't find one that could easily be adapted to the end-user wishes (i.e. a good zoom facility). So I decided to write my own, which is finished now and works great for my purposes.
And now the interesting part, if I stood at the start of this part right now, I would probably go for MatPlotLib. You probably all saw the awesome website of MatPlotLib, now with lots of clear examples and a good explanation of the dual interface and very good and full documentation, really beautiful !!.
For those who have missed it: http://matplotlib.sourceforge.net/gallery.html

3. For the 2D (3D) animation, I didn't see anything in wxPython (remember how I interpretated FloatCanvas, and I wonder how many others will draw the same conclusion). I never got GLopen to work, so I searched and then there seems to be only 1 answer: VPython. Investigating VPython, which had all capabilities and a very clear and unbelievable simple api, there was only 1 essential problem: it couldn't work with wxPython, because both have a main loop (later on I realized that was wrong). Now if I leave the 3D out, OGL-like has almost everything I needed, so I extended OGL-like. Just a couple of days ago, I got involved in a discussion in the VPython list, where it was proven that you can control VPython almost perfectly from wxPython and even embed it !
So again if I had all the knowledge at the moment of my decision, I probably would have chosen different.

So having a very good technical library is far not enough to make the library a common success.
The documentation, examples, an very easy step-in possibility, simplicity of extending the library are possibly far more important factors.
Although I didn't got your code running, I see Matlab / MatPlotLib like buttons, ggrrrr
Don't copy before you've thought twice about it.
I think most people agree that google makes good tools, no very good tools, study how google zooms.

Hopefully this historical review made it clear why I made certain choices.
If you think I'm an exception (which I certainly am ;-),
keep on the good work on the core of the program,
otherwise put your effort in the surrounding (can't find the right word) of the program.

cheers,
Stef

···

On the other hand, the 2D-scene I showed is just a docking place for ANY 2D library,
the code in the editor on the left controls the whole 2D scene,
so it would be nice to fit floatcanvas too,
just give me little piece of code that does soemthing similar, and I'll show how easy it fits into.

Enclosed.

I brought this up again, because that kind of thing is exactly what FloatCanvas is made for -- giving a visual representation of some kind of data.

You can see that the drawing part of the demo I've enclosed is trivial. (so is the physics, but I didn't do that well!)

One note: I discovered a bug in the FloatCanvas Circle object when I wrote this, so the ball shifts a bit if you use the version built into wxPython. It has been fixed in SVN.

-Chris

------------------------------------------------------------------------

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Christopher Barker wrote:

Stef Mientki wrote:

I doesn't run at my place :frowning:

       self.Ball = Canvas.AddObject( Ball( (5, 52), (1,1) ) )
       print type(self.Ball), self.Ball

using installed version: 0.9.18
<type 'bool'> True

Do I have an (too) old version of Floatcanvas.

could be -- I thought AddObject() always returned the object, but who knows? This should work:

        # add the ball:
        self.Ball = Ball( (5, 52), (1,1) )
        Canvas.AddObject( self.Ball )

thanks Chris,
that works, so now I have to start working on it :wink:
cheers,
Stef

Stef Mientki wrote:

here the rest of the story.

Interesting, and I think one of the key conclusions is that open-source projects do need to do good marketing if they want to get used.

However, like everyone else, I don't have much spare time, and coding is more fun than marketing.

For my first large application I needed:
1- graphical schematic editor, that could draw blocks and connect them
2- a plot library to plot amplitude - time signals
3- a 2D (3D) animation for physics processes

Of course I would like to do all my 3 needs with just 1 library, but looking at the above, that seems to be impossible.

In theory, both (1) and (2) could be built on the a good 2d (or even maybe 3d) lib, but everyone want to build what they want, not a lib to built it on.

Matthias wants to build (1) on top of FloatCanvas2, so we'll see.

I also aksed help on this forum, but no one really seems to use it and looking into the code,

you do need a maintainer. also, I think OGL was "translated" from the C++ version, so it may not be very "pythonic"

2. for the plotting of amplitude-time curves, MatPlotLib seemed to be answer.

and probably was....

in MatPlotLib :wink: In doing some exercises with MatPlotLib, having limiting examples, not understanding the dual interface to MatPlotLib,

Yes, I've frustrated for a long time that most of the MPL docs are all using the pylab interface, and the dreaded "import *", I think it really does a poor job of showing its power as an embedded graphing lib.

Did you check out Chaco as well?

You probably all saw the awesome website of MatPlotLib, now with lots of clear examples and a good explanation of the dual interface and very good and full documentation, really beautiful !!.

Docs really do make the difference.

3. For the 2D (3D) animation, I didn't see anything in wxPython (remember how I interpretated FloatCanvas, and I wonder how many others will draw the same conclusion).

I suppose one of these days I"ll try to put some better introductory docs together. It's probably not such a good thing that the main demo is really a test that throws up everything it can draw in one big mess!

searched and then there seems to be only 1 answer: VPython.

This may indeed be exactly what you want.

Although I didn't got your code running, I see Matlab / MatPlotLib like buttons, ggrrrr

They have nothing to do with Matlab or Matplotlib -- I stopped using Matlab before they had anything like that, and FloatCanvas pre-dates MPL too. Also, the buttons are an add-on - you can navigate the canvas any way you like.

But anyway, what's wrong with them?

I think most people agree that google makes good tools, no very good tools, study how google zooms.

which google are we talking about?

But FloatCanvas does support using the scroll wheel to zoom in and out now, if that's what you mean.

However, what this underscores is that it's not easy to easily find FloatCanvas' purpose and capabilities.

Hopefully this historical review made it clear why I made certain choices.
If you think I'm an exception (which I certainly am ;-),

Well, I'm sure you're exceptional, but I don't think your impressions are unusual.

Thanks for the input,

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Erm, not to hijack this thread too much but...

Stef Mientki wrote:

[snip]

in MatPlotLib :wink: In doing some exercises with MatPlotLib, having
limiting examples, not understanding the dual interface to MatPlotLib,

Yes, I've frustrated for a long time that most of the MPL docs are all using
the pylab interface, and the dreaded "import *", I think it really does a
poor job of showing its power as an embedded graphing lib.

Did you check out Chaco as well?

We were evaluating plotting toolkits 12 (18?) months ago and briefly
looked at Chaco. It looked interesting, but the state of the
documentation was abysmal (mostly only in the source code), examples
were hard to come by, and there didn't seem to be the same community
that mpl had. Having built our app on mpl now, we're extremely happy
and have no compelling reasons to look at any other plotting library.

The embedding API for MPL is well documented (although ... as it turns
out ... mostly in the source code and/or epydoc-generated pages) and
quite powerful.

Cheers,
Anthony.

···

On Thu, Nov 6, 2008 at 3:37 PM, Christopher Barker <Chris.Barker@noaa.gov> wrote:

hi Chris,

Christopher Barker wrote:

Stef Mientki wrote:

here the rest of the story.

Interesting, and I think one of the key conclusions is that open-source projects do need to do good marketing if they want to get used.

However, like everyone else, I don't have much spare time, and coding is more fun than marketing.

Yes I've exactly the same feelings.

For my first large application I needed:
1- graphical schematic editor, that could draw blocks and connect them
2- a plot library to plot amplitude - time signals
3- a 2D (3D) animation for physics processes

Of course I would like to do all my 3 needs with just 1 library, but looking at the above, that seems to be impossible.

In theory, both (1) and (2) could be built on the a good 2d (or even maybe 3d) lib, but everyone want to build what they want, not a lib to built it on.

Matthias wants to build (1) on top of FloatCanvas2, so we'll see.

I also aksed help on this forum, but no one really seems to use it and looking into the code,

you do need a maintainer. also, I think OGL was "translated" from the C++ version, so it may not be very "pythonic"

2. for the plotting of amplitude-time curves, MatPlotLib seemed to be answer.

and probably was....

in MatPlotLib :wink: In doing some exercises with MatPlotLib, having limiting examples, not understanding the dual interface to MatPlotLib,

Yes, I've frustrated for a long time that most of the MPL docs are all using the pylab interface, and the dreaded "import *", I think it really does a poor job of showing its power as an embedded graphing lib.

Did you check out Chaco as well?

At the time of the decision I don't think I knew Chaco, but I'm not sure.
I've seen it later on, and agree with Anthony, the documentation is not sufficient, and ....
... I'm terribly afraid of Traits !!
btw I have to admit that the chosen color pallets are beautiful, positive marketing !

You probably all saw the awesome website of MatPlotLib, now with lots of clear examples and a good explanation of the dual interface and very good and full documentation, really beautiful !!.

Docs really do make the difference.

3. For the 2D (3D) animation, I didn't see anything in wxPython (remember how I interpretated FloatCanvas, and I wonder how many others will draw the same conclusion).

I suppose one of these days I"ll try to put some better introductory docs together. It's probably not such a good thing that the main demo is really a test that throws up everything it can draw in one big mess!

searched and then there seems to be only 1 answer: VPython.

This may indeed be exactly what you want.

Although I didn't got your code running, I see Matlab / MatPlotLib like buttons, ggrrrr

They have nothing to do with Matlab or Matplotlib -- I stopped using Matlab before they had anything like that, and FloatCanvas pre-dates MPL too. Also, the buttons are an add-on - you can navigate the canvas any way you like.

But anyway, what's wrong with them?

I think most people agree that google makes good tools, no very good tools, study how google zooms.

which google are we talking about?

But FloatCanvas does support using the scroll wheel to zoom in and out now, if that's what you mean.

Didin't know about the scrollwheel, but it doesn't change, because just like almost all my colleagues, I use a pen :wink:
And that's why we have so much trouble, a pen is 5 to 10 times faster than a mouse.

What's so special about googles zoom, well nothing special, because all programs we develop have the same options :wink:
Here a few features of "Google's zoom" , that are missing in Floatcanvas, MPL, MatLab, VPython, ....:
- you always see some kind of total overview, and in that total view you can see where you zoomed part is
- there are buttons that stepwise (factor 2 or so) zoom in or out, you could easily achieve that by using the button press when the button is already down
- you can move the selected zoom window over the signal
- you can zoom a certain value
- when zoomed you can jump to a certain position (can be done in the overview), or specify coordinates

However, what this underscores is that it's not easy to easily find FloatCanvas' purpose and capabilities.

Indeed,

Hopefully this historical review made it clear why I made certain choices.
If you think I'm an exception (which I certainly am ;-),

Well, I'm sure you're exceptional, but I don't think your impressions are unusual.

Thanks for the input,

your welcome.
I hope you can do something constructive with the input.

cheers,
Stef

···

-Chris

hi Chris,

got it running, very interesting experiment.
I compared 3 implementations:
- 2D_Scene, flickerfree
- VPython, flickerfree but need some command to prevent autoscaling
-FLoatCanvas, flickers like hell,
now the funny thing is that it doesn't flicker at all in the recording, not one image ???
Looks like it has something todo with my screen refresh rate ??
My screen refresh rate is 60 Hz, the recording was made with 20 Hz.

you can see the recording here (3MB)
  http://mientki.ruhosting.nl/data_www/demos/2d_scene_1.html

The experiment was interesting because,
- I found a few bugs
- I found a number of possible generalization, I think I can implement any drawing canvas in about 10 .. 20 lines of code

As floatcanvas hasn't all the geometries, like sphere etc,
it will be a lot of work to implement Floatcanvas as a full working tool,
so for the moment I'll stop with floatcanvas.

thanks for the support,
cheers,
Stef

Stef Mientki wrote:

got it running, very interesting experiment.
-FLoatCanvas, flickers like hell,
now the funny thing is that it doesn't flicker at all in the recording, not one image ???
Looks like it has something todo with my screen refresh rate ??
My screen refresh rate is 60 Hz, the recording was made with 20 Hz.

you can see the recording here (3MB)
http://mientki.ruhosting.nl/data_www/demos/2d_scene_1.html

I can run that flash moving and don't see any flickering at all.

Just to be clear, when you just run it on your machine and look at it, you don't get any flicker?

- I found a number of possible generalization, I think I can implement any drawing canvas in about 10 .. 20 lines of code

nice.

As floatcanvas hasn't all the geometries, like sphere etc,

It's 2-d, what would a sphere be? As for other geometries, it's not hard to add a new one -- very little code depending on how complex your object is.

it will be a lot of work to implement Floatcanvas as a full working tool,
so for the moment I'll stop with floatcanvas.

For that example, VPython is exactly what you want.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov