How Gideros processes higher resolution images

moopf

This has been spawned from this thread:

http://www.giderosmobile.com/forum/discussion/1891/problem-with-bm-font-glyph-designer-automatic-scalling#Item_4

I remember @atilim mentioning a while ago that for higher resolution images, Gideros first opens the SD image to get dimensions, to scale accordingly, before opening the actual asset you want to use. This seems a little wasteful and also is the reason behind GlyphDesigner not working correctly with the system. As we're setting image extensions and scales in the project properties, why is this being done in this way - can't you just open the correct resolution image and work out the correct size from the scales set in the project? Surely it's the developer's responsibility to ensure that @2x images are really x 2 in dimensions.

For GlyphDesigner the problem is arising that there's no guarantee that a higher resolution font png will actually be double the size of the sd version, for example. That's because of alignment and font sizing issues (plus differences in text effects you may want to apply) so basing scaling and sizing off the sd version leads to incorrect rendering (this is using BMFont). I'm using bmGlyph now but simple resizing for lower res versions of a font does lead to some unwanted side-effects, such as alignment issues.

Wouldn't changing the core to only base things on the higher resolution images (and if not available, open lower res and scale up accordingly) be better for Gideros as a whole? There must be an overhead in opening the SD images first. I have no idea how much work this would be so apologies if it's a huge undertaking. This would also get around the situation I thought of a while ago and posted about, one where you download higher resolution imagery where required for an app rather than including it all as standard in the package.

Have I got the wrong end of the stick here? (Possible!)

moopf

UPDATE: I've solved the GlyphDesigner issue by making alterations in BMFont and doing some calculation of scaling to get it to interpret the texture correctly from the correct .fnt file (see the thread linked to above for the solution). However the point still remains and I'd love to get an explanation as to why Gideros uses the SD version at all when displaying higher resolution images. If nothing else it has to be a performance impact surely.

atilim

You've already said the reason of using the base image's dimensions: "Surely it's the developer's responsibility to ensure that @2x images are really x 2 in dimensions." If the developer doesn't provide exact x2 in dimensions for @2x images, they wouldn't be displayed at correct size. I think everything should be displayed exactly at the same size when the scaling changes. Here the dimensions of the base image is my constant.

I assume reading the header info of the base image is negligible compared to reading the full image data. (But I haven't measured that)

moopf

Hi @atilim - yes, I thought that was the reason. Do you mind if I make a case for why I don't think that's in the best interests of Gideros. Being able to scale an image exactly is a pretty fundamental use of any graphics package but in writing Gideros in a way that tries to catch such fundamental mistakes, and compensate for them, it's actually dumbing down the system and taking control away from the developer.

If you took this away there's a few things that would sort themselves out:

1. The scaling on BMFont (or any other such class that would work with different ratio images depending on resolutions, for texture memory efficiency, but doesn't currently without clunky changes).
2. The ability to have your app download art assets suitable for the device it's running on without needing to have the lowest resolution version as well. And by association this should solve the problem that the downloaded artwork would be in a different directory to the lowest resolution version as that just wouldn't be needed any longer.
3. Every file access on mobile carries an overhead - it may not be much, but it's all about efficiency and anything that can be done to improve that is a bonus.
4. A developer could actually use images that display larger on lower resolution phones etc. which could well be useful. Point is, they have control over it.

Anyway, that's the 4 I can think of at the moment but I'm sure there's more. I'd suggest adding a flag in project settings to turn this off to give those developers that want the freedom the ability to do so but I feel that then we'll get into a position where code people share will only work if the flag is on or off.

I can understand why you'd want to do Gideros in this way originally but, in my opinion, I'm not sure it's worth the trade-off as it introduces some artificial limits on what a developer can do.

moopf

Knew I'd think of another example! I like to provide different sized buttons on tablets than on mobiles, otherwise I find that buttons looks ridiculously over-sized on a user interface on tablets (due to the nature of the lower DPI). To do this currently I'd need to also have an sd version of the button imagery specific for tablets so that Gideros could correctly resize it even though I wouldn't actually ever use it to display, which is a little wasteful.

Mells

@moopf
That discussion is interesting, I'm also curious about the points you have raised.