Read comments below...
--- Hans Meine <[EMAIL PROTECTED]> wrote:
> On Sonntag 19 August 2007, Michael Beal wrote:
> > Then the ratio calculations are faulty and need to be addressed.
>
> Michael, maybe it's just me, but I read a lot of unproductive
> criticism in your postings.
Still waiting for you to make a valid point about this. You do have
one, correct?
> > Images which, by pixel dimensions, are square get stretched out of
> > shape. According to what's being said, the skinning engine should
> > display images at their designed/intended size with _zero_
> > distortion because everything is being adjusted based on screen
> > aspect.
>
> There's no RYM ("read your mind") mode in the skinning engine.
> However, as you seem to have realized, the skinning engine *does*
> scale based on the ratio between the configured screen geometry and
> the skin size. This is intended and does work for sizes larger than
> 800x600 (which a lot of people - e.g. me - do use).
As I said, an image which, by pixel dimensions, is square (e.g.
256x256) will get stretched beyond belief when using Freevo in
fullscreen mode in anything outside of the default.
> > I think everyone is caught up in the "programming intent" behind
> > the skins and ignoring the reality of it all. The intent is for
> > everything to self-adapt, with the engine placing things where
> > they should go. The reality is this doesn't happen at screen
> > resolutions over the default 800x600. If I have my freevo.conf
> > geometry at 800x600, choose a skin built for 800x600 and do
> > "freevo -fs" from the command line, I get icons and images that
> > are stretched. This is to be expected, correct?
>
> AFAICS, yes (for your setup). The stretching probably happens in the
> X server or monitor - e.g. on my thinkpad, it would *not* necessarily
> stretch, but simply show a smaller region in the middle of the
screen.
CORRECT!!! That's _exactly_ where the image stretch comes from! Now,
the question is _why_?? Because Freevo, when started with the "-fs"
option, launches a new X server with the geometry specified in the
freevo.conf. There is no way to avoid this unless Freevo is changed to
spawn X using system defaults rather than specifying for it's own
needs.
I, however, don't get that "smaller region in the middle of the
screen"; I obviously get a stretched out skin.
> > If I change my freevo.conf to *my* default of 1440x900 and do
> > everything else the same way, will I get images and icons displayed
> > correctly? No, I don't.
>
> That depends on your definition of "correctly". Recall that the
> image regions defined in the skin are given in pixels that mean
> sth. like "percent". Thus, if the scaling ratio is larger in one
> dimension than in the other, I would expect images to be stretched.
"Correctly" means "as originally drawn." I don't see where that's even
a question.
The image regions in the skin are defined by a start _point_, the X and
Y coords of the top left pixel. Width and Height can then be defined
as a constraining area for the image to "live" in and conform to.
This, in part, is the rub of this situation.
> > Images are still stretched and, if I'm understanding your
> > contention, these pictures shouldn't be. However, if I change the
> > third line in any skin from 'geometry="800x600">' to
> > 'geometry="1440x900">' then I get nice, pretty, properly displayed
> > images and icons, although everything is shoved into the top left
> > corner. So why isn't the skinning engine correctly displaying
> > images at the intended size and shape?
>
> For displaying images at the "intended" size and shape, it would be
> necessary to know it.
Imlib can gather that information.
> Looking at the skin files, I only see <image>
> elements either without a size set (I assume width,height are then
> read from the file) or with both set. Now how should the skin engine
> display the images? One straightforward interpretation is
> width*hori_factor, height*vert_factor. As hori_factor and
vert_factor
> differ, the image becomes stretched.
>
> What you obviously want, is that the aspect ratio of some images (not
> all, e.g. the background image) to be retained. This could be done
by
> some kind of "maxfit" algorithm, e.g. centering the image within the
> specified rectangle. AFAICS, there is not much information about
what
> you want that Freevo currently gets from the skin .fxd files.
>
> Speaking of that, I wonder if it is intentional that object.width and
> object.height are not handled alike in area.py, lines 395 and 398.
> The object.width looks very strange to me actually, as if an " +
> self.area_val.x" was missing in there.
This may be very true. I haven't looked over that portion of the code
in a _long_ while.
> Your sought formula is no black magic.
The formula I am working out is in regards to image _placement_ via
percentages of actual screen dimensions, not image _display_ or aspect.
Not sure if that was unclear; just clarifying. I can say that this
isn't going very easily either. As screen dimensions change, the
resultant multiplier changes radically. I'm going to try the
previously mentioned possibility of setting _skin_ geometry to 100x100
to see if the end result comes close to my desired concept.
> Given an image file with either square pixels or a known aspect
> ratio, it is trivial to display it correctly *given enough
> information*:
>
> - The screen resolution and size (-> aspect ratio
> can be computed) can be queried from X, but note that Freevo is
> not X-only and these values would have to pass an intermediate
> layer. (But it would be easy to add an additional "displaysize"
> parameter to freevo.conf, with the mm width&height in analogy to
> the "DisplaySize" option in the "Monitor" section of xorg.conf.)
>
> - The scaling mode (e.g. fit width to height, vice versa or maxpect /
> fillarea)
>
> I see absolutely no need for anamorphic skins or for pre-scaled
> images though. Creating 16:9 skins is a different matter, that
> could make sense AFAICS because other layouts become more feasible.
Thank you! Seems like double work to me too.
> After writing all this, I see Jean-Michel mention Panorama to be an
> anamorphic skin. I don't know much about the old skin engine
> (which is about to change a lot for Freevo2 anyways), but this looks
> like a workaround for displays (e.g. the mentioned UK ones) where
> the actual screen size is not known and the resolution aspect is 4:3.
> I would hope that using a real 16:9 skin and configuring `geometry`
> in /etc/freevo.conf to be the 4:3 aspect would also help, but all
> that depends on the ability to scale images "correctly", which has
> the two abovementioned requirements that "correctly" is defined
> (i.e. in the skin) and that the skin engine has enough knowledge
> about the display.
One suggestion which I've yet to try out, concerning defining skins in
percentages via setting the skin geometry to 100x100, may be the most
viable for truly "self-adapting" skins. And, Hans, your input has
prompted another possible option for me to test out: leaving out the
width and height constraints in a 100x100 skin. This may result in a
horrible crash or a whole new way of looking at the skins. I can only
test and report back. And I shall. When time permits.
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo!
FareChase.
http://farechase.yahoo.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
