I started to make the changes into CN1 source code to improve how densities are handled. One of the only issue I have is that currently density constants are small int values that actually do not match the PPI (pixels per inch) density. It would make more sense to have them as PPI values (like android does). What is the reason of not having them directly as PPI values (there might be some not obvious good reason that I do not see)? Do you see any objection of having them changed to PPI values (it would also requiere to handle some special case for MultipleImages created before this change as, if I understood correctly, these density values are used to identify the matching image for the device resolution. So if a density coded into a multipleImage is <=80 it would have to be converted to PPI before testing (but PPI values < 80 do not make sense on any device used nowadays, so this test should not be an issue)). Appart from that, for iOS devices, I was thinking of having a hard coded conversion map between devices models and their PPI (the list iOS devices is short so it is something that is quite easy to maintain. If the device is not in the list it would default to the PPI assumption, like for android devices anyway, so it doesn't really matter if the list of devices is not up to date). For Android, I was thinking of using xdpi and ydpi and see if the PPI obtain with these values do not deviate too much from the estimated PPI (based on device resolution), if not, I keep that value that should be more precise than the estimated one, else I default to the estimate (as xdpi and ydpi might be erroneous) For other platforms, I don't know what whould be the best approach (on windows desktops, the ppi is a system variable that is 96 by default and can be changed by the user, so maybe taking this value if not at 96 could be an idea...?) so I would befault to the PPI assumption based on resolution for now... Sounds good to you? If yes I would probably send a pull request with these changes in the comming days.
On Wednesday, May 9, 2018 at 6:28:08 AM UTC+2, Shai Almog wrote: > > We do that because the precise information doesn't actually work. > That might have changed for newer devices by now so it might make sense to > revisit that but back when we launched it turned out that Google didn't > check these values for devices. So a lot of manufacturers just didn't > update them when building new devices and we ended up with huge > discrepancies. Notice that this was during the 2.x era so it might be a > good idea to add some test logic that verifies the approximate values so > this works universally and accurately. > -- You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/codenameone-discussions. To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/e5499e1e-5380-4e52-b4a3-0b8758bb9f15%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
