J. Landman Gay wrote:
On 6/5/05 4:33 PM, Jon wrote:
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.
You should be able to do this easily, and I know of several image
viewers that others have done. It is a trivial task in Revolution, and
very fast. There are so many image commands and features that you
should never need to manipulate individual pixel data except in the
most unusual cases. For a standard image viewer project, never.
My viewer is not a standard viewer. I've implemented a variety of
useful features that require that I manage each pixel individually
(basically doing custom and complex brightness and contrast
stretching). Rev is way too slow to do anything like that.
This is an excellent first-time project. It should be possible to
write a simple image viewer in a handful of lines. You can display an
image from disk in a single line of Transcript. You can set its size
in one more line. What did you need to do exactly? Maybe we can help
you finish this.
You can download my Windows image viewer if you root around in
www.jonbondy.com a bit if you want to see the features I've
implemented. Image sizing is a very difficult thing in Rev: the default
seems to be either 1:1 display (which often is too large to fit in the
allocated space) or horrible distortion when the image is forced into
the limits of the enclosure. I can write software to fix all of this,
but I decided to move on to another project (the audio/video player)
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.
LockLoc is short for "lock location" and can also be written
"locklocation". ;) It overcomes the default behavior of images, which
is to automatically expand to fit their image contents.
This is not locking a location; it is altering the image expansion
behavior. I find some of this nomenclature to be very bizarre.
When you put an image from disk into an image object, it will
automatically resize to fit the image content. If you do not want this
behavior, you lock the location (that is, you prevent resizing) by
setting the lockLoc to true. When an image is locked this way, its
contents will *scale* to fit the image object, rather than the object
scaling to fit the image content.
True, but it will scale in both directions, distorting it horribly.
This is not useful behavior, unless you want to fill a large space with
a small speck of blue. It's ok for backrgounds, not for actual images.
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.
I have it somewhere but I'd have to go search for it. It isn't too
hard though. You just get the width of the available space and the
height of the available space, then compare them to see which is
larger. Use the largest one to calculate a ratio. Multiply that ratio
times the formattedwidth of the image to get the new width; multiply
it times the formattedheight of the image to get the new height.
If you can't figure it out, post again and I will go look for it. I
can't remember which project I put it in. ;)
Yeah: the logic is straightforward if you work it out. I just feel as
if this should be an intrinsic part of images. And I ran into some huge
bugs when I accidentally mixed an image with Geometry with an On Resize
handler.
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.
As per above, if you leave the lockloc of the image object set to
false, the image will automatically resize to the native dimensions.
As per above, the image will be impossible to see, since it will be so
distorted
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.
I'm not sure what you are after exactly, but these can all be retrieved.
Pixel size on disk: formattedwidth and formattedheight of the image.
Space available on screen: you'll have to calculate that, or if it is
always the same, store it as a constant, a property or a variable, etc.
Actual space used on screen: you can get either the rect of the image,
or you can get the width and the height of the image. This represents
the actual current size of the image object.
Maybe this is better left as a phone conversation <grin>
Jon
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution
