dump newbie image questiosn

[John Ridge]

Hi John

I was impressed by your exchanges with Jaqueline LG - what you are talking
about is way beyond my capability. And Rev's also, she suggests?

Anyway, for what it's worth I've put my little stack in the user space -
user "jmr", and the stack is called "image testbed". Note that you can grab
the image by a mouseDown and move it around. On my rather elderly G4 this
gives very jerky movement with large jpegs... Would it help to throw
hardware at the problem?
-- 


From: Jon <jbondy at sover.net>
Reply-To: How to use Revolution <use-revolution at lists.runrev.com>
Date: Sun, 05 Jun 2005 17:33:48 -0400
To: How to use Revolution <use-revolution at lists.runrev.com>
Subject: Re: dump newbie image questiosn


John:

Yes, I'm interested.

My first learning project was to replicate my Windows image
viewer/manipulator in Rev.  That ended with some finality when it turned
out that Rev runs so slowly that it cannot possibly process all of the
pixels in a real image in the time a reasonable user would sit still.  Sigh.

I'm now working on a special music/video player, again "porting" it from
a Windows implementation.  It's almost finished (in the sense that all
of the features seem to work at least once!), but needs a lot of
cosmetic work and then lots of testing.   I am displaying guitar
tablature in an image along the bottom of the screen.  I want the image
to "squeeze" into the given box, but NOT be distorted (a fairly obvious
need in my opinion).  So, I need to write (or steal!) the logic that
figures out which dimension needs to be adjusted, and then adjust it,
and then use the LockLoc (what a strange and unintuitive name!) to let
it expand to fill the properly proportioned image container.

A snippet of code would suffice, although I've written this code enough
times that I'm sure I could figure it out again.  I am more annoyed that
I even have to than anything else.

The Geometry facility is interesting (and novel to me), but I don't know
that it will work at all with the kinds of things I want to do.  Because
I don't want to distort any images, I will end up altering the shape of
the Image object each time an image is loaded.  Eventually, it will be
easy to lose track of the original shape/size of the "container" into
which I was trying to stuff the images.  There is a concept missing
here, I think: we need THREE image sizes (pixel size on disk, size of
largest space available on the screen, and actual space used on the
screen) rather than the two (first and last, above) that is currently
available.  I'm spoiled: all of this was available in a single mode
property in my previous IDE.

:)

Jon

John Ridge wrote:

>Did you get any response to this query? If so, I've missed it - no surprise,
>given the volume!
>
>I got interested in the issue, and have been playing with the lockLoc
>property of the image. I do find the language confusing - the "image" is the
>control within which you display a JPEG (say). When lockLoc is true, the
>image (the control) stays as is, and the picture is forced to fit within it
>- which can lead to  massive distortion, of course. When lockLoc is false
>(the default) the picture arrives in its native size - so your image may
>turn out to be a small window into it. You can grab the image and slide it
>around under the window. I've also done a ShrinkToFit handler, but I bet
>there are better ways of doing the job!
>
>If you're interested, I can send the stack to the User Space, or
>somewhere...
>
>Regards,
>John
>  
>