wxperl-users

Re: [wxperl-users] Handling a large zoomable image (world map)

[Donovan A. <al...@Zo...>]

The method described below is the direction I would take, but treating =
it more like a tiled 2d game.
=20
In more modern (heh) 2d tile map games, there is a "viewport rectangle" =
and a "worldview rectangle".  You draw only the viewport rectangle's =
tiles, but you store an extra amount of neighboring tiles (the size of =
which is more like a worldview).  As the viewport is moved, free the =
tiles that are now outside of the worldview rectangle and load (in a =
thread perhaps?) the new (non-visible) "worldview rectangles".
=20
This provides efficient memory use & smoother loading at the cost of =
greater complexity & having to break your source image into tiles (which =
you do once and save the tiles and a map of coords to the specific =
tiles).
=20
Anyway, just some more food for thought.  If you go this route, there is =
plenty of reading out there on this topic for 2d games.

=20
________________________________

From: wxp...@li... on behalf of Jouke =
Visser
Sent: Tue 6/27/2006 6:37 AM
To: Ed W
Cc: wxp...@li...
Subject: Re: [wxperl-users] Handling a large zoomable image (world map)



Hi Ed,

> Oooh.  I say!  Now that looks really nice for all kinds of reasons!
> Thanks for creating this
My pleasure. If you encounter any bugs, let me know via CPAN's RT.

> What's likely the best technique to handle an oversized image with a
> small viewport in Image:Magick?  I'm guessing that I will have to use =
a
> static image and some slider bars to emulate the effect of a viewport =
on
> a much larger sub image?  Are there any other useful features in
> Image::Magick which can help support the viewport kind of model?
Well, you could take the original image, and crop (see the crop method
in Image::Magick's documentation) pieces of it and put that in your
window. When the user wants to scroll a whole page in any direction
(north, east, south or west), you could crop again from the original,
and if someone would just want to move in any direction for only a few
pixels, maybe it's faster to crop that extra bit and add it to the copy
you're already displaying. You can easily "montage" (see IM docs again)
several pieces together...

Since Wx::Perl::Imagick gives you more image manipulation possibilities,
you could also choose to put a kind of compass on top of your image and
let the user use that for navigation, or whatever you'd want.

I usually get the best ideas for solving my Image manipulation issues by
browsing through Image::Magick's documentation (a link to that can be
found in the Wx::Perl::Imagick POD), and read what the various methods =
do.

HTH,

Jouke

Using Tomcat but need to do more? Need to support web services, =
security?
Get stuff done quickly with pre-integrated technology to make your job =
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
wxperl-users mailing list
wxp...@li...
https://lists.sourceforge.net/lists/listinfo/wxperl-users

Re: [wxperl-users] Handling a large zoomable image (world map)

[Donovan A. <al...@Zo...>]

I am using POE, Wx and POE::Loop::Wx in a production application. =20
=20
POE is pretty cool, but my feelings on it are a mixed bag. =20
=20
Part of my app samples input from digital & analog IO hardware, and I =
had to break that component into it's own app because of decreased =
resolution on poe events in the kernel when using POE::Loop::Wx.
=20
Simply removing the POE::Loop::Wx from this second app gave me back =
0.3-0.5 seconds or so in every second for session events.  It may be =
simple enough to tweak with the timing in the loop or it may simply be =
that processing the Wx events is taking a rather long time (which might =
be able to be solved by breaking a function into more parts), but I =
haven't looked very deeply into it.
=20
There are both pros and cons for POE (as with any system).  I don't have =
a ton of time right now to go into an in depth analysis for you, but =
since the pros are well known, the few important cons/considerations =
that I perceive are:
=20
1> POE will not take advantage of multiple processors and given modern =
processors, this could be a big deal for your code.
=20
2> On a similar note, since it is a single process, you can't take =
advantage of the time spent reading a file (low CPU use) to get =
something else done. =20
=20
3> POE is a pretty complicated framework, which given all it does is =
understandable, but depending on your project, it may be less =
complicated to use threads, threads::shared, and the Event module. =20
=20
4> Since nothing is running in parallel, you have to chop your time =
consuming functions into smaller processing units and at the end of =
"middle units" (forgot the term POE uses), you have to issue a call to =
POE to add the next unit call on the queue.
=20
This is a serious commitment to POE (at least without careful design - =
and maybe not even then) as moving to some other model later becomes =
much more difficult (as opposed to say, using the "forks" module and =
threads interchangeably).
=20
5> Related to the last con, is that you may find yourself reinventing =
wheels (hoho - POE humor), since any CPAN module you use may ruin your =
day and need to be rewritten to do things the POE way.  And if you think =
I jest, look at CPAN's POE modules...it is very much a lot of CPAN =
modules wrapped or modified for POE.
=20
After reading all this, it should become clear that the best solution =
overall would be to use POE with threads.  Well, officially threads and =
POE are not compatible (the CPAN POE threads module is using the old =
perl threads and was really just an experiment) and unofficially it is =
doable, but at such a high memory overhead that it is not realistic. =20
=20
Now, all this being said, POE does what it says on the tin, the project =
your proposing is probably doable with it and it is possible to use POE =
+ Wx for production quality product (as I have done and I believe at =
least someone else has - the devs of POE::Loop::Wx), but you might =
consider doing some serious homework on this first.
=20
Wow...that was longer than intended...lol.

________________________________

From: Ed W [mailto:li...@wi...]
Sent: Wed 6/28/2006 2:07 AM
To: Eriam Schaffter
Cc: Donovan Allen; Jouke Visser; wxp...@li...
Subject: Re: [wxperl-users] Handling a large zoomable image (world map)


Eriam Schaffter wrote:=20

	Le Mer 28 juin 2006 1:20, Donovan Allen a =E9crit :
	 =20

		(in a thread
		perhaps?)
		   =20

	May I suggest POE ?
=09
	I think that would be a perfect fit for this situation !
=09
	You can have a look at POE::Loop::Wx
	 =20


POE is a great suggestion and I have played with it a little already.  =
Actually my first instinct was NOT to use POE on the client end of this =
system (mainly win32) because on the surface it looked as though POE =
might be quite slow?

The application also acts as a network proxy for some other network =
stuff and it would be useful to have it all in one exe process.  Anyone =
got any real world statistics on whether POE is slow and heavy, or =
decently speedy in the real world?

Thanks for all the suggestions so far.  For sure the double viewport =
suggestion is what I was heading towards, but the implementation wasn't =
so clear in my mind until you paraphrased the algorithm so neatly.  =
Thanks

Ed W

Re: [wxperl-users] Handling a large zoomable image (world map)

[Eriam S. <er...@er...>]

Le Mer 28 juin 2006 1:20, Donovan Allen a =E9crit :
> (in a thread
> perhaps?)


May I suggest POE ?

I think that would be a perfect fit for this situation !

You can have a look at POE::Loop::Wx

Thank you

Eriam

Re: [wxperl-users] Handling a large zoomable image (world map)

[Ed W <li...@wi...>]

Eriam Schaffter wrote:
> Le Mer 28 juin 2006 1:20, Donovan Allen a =E9crit :
>  =20
>> (in a thread
>> perhaps?)
>>    =20
>
>
> May I suggest POE ?
>
> I think that would be a perfect fit for this situation !
>
> You can have a look at POE::Loop::Wx
>  =20

POE is a great suggestion and I have played with it a little already. =20
Actually my first instinct was NOT to use POE on the client end of this=20
system (mainly win32) because on the surface it looked as though POE=20
might be quite slow?

The application also acts as a network proxy for some other network=20
stuff and it would be useful to have it all in one exe process.  Anyone=20
got any real world statistics on whether POE is slow and heavy, or=20
decently speedy in the real world?

Thanks for all the suggestions so far.  For sure the double viewport=20
suggestion is what I was heading towards, but the implementation wasn't=20
so clear in my mind until you paraphrased the algorithm so neatly.  Thank=
s

Ed W