On 19/12/10 14:36, Matthias Melcher wrote: > - should coordinates be in Floating Point?
And if we say floating point, do we actually mean float or double? Given that we probably need to be able to do integer exact values too for some rendering cases, a float only has (say) 24 usable bits of resolution - more than 1.1 has (16-bits) but less than 1.3 has (32-bits). But does that matter? 24-bits worth of pixels is still a very long way (even at 280 dpi or whatever it is you get on a "retinal" display - say three-quarters of a km or so. That's quite a big display!) A float would use the same storage per widget as the current 1.3 co-ords, but if we need to go to doubles, that makes the co-ords bigger (on most current platforms...) Though that probably doesn't matter all that much, I think. I'd assume that we really mean doubles though - and that probably ties in better with what other systems are doing, I think? My big worry with this would be that some of the platforms we might reasonably be targeting (e.g. some ARM targets etc.) don't have real FP hardware, so they are noticeably slower doing FP calcs than they are doing integer. (In days of yore, when I started out, FP was waaaay slower than integer, but that's not really the case any more - except on targets that don't have real FPU hardware...) > - should font sizes be in FP? I guess so, if the co-ords are. > - how can we add an alpha channel (transparency) to our color setup > (and keep the color lookup table at the same time)? Ugh. 64-bit colour types anyone? Sort of RGBAxxxI, where the x's are the bytes we haven't thought of yet, obviously! > - how doe we handle screen resolution? Dunno. What does GL do, or Cairo? > There are many more types that need to be reevaluated: > > - fonts are indices - shouldn't they be a pointer? > - box types are indices - pointer? > - labeltypes are integers - they could be pointers? All of the above, I don't know... I guess that could make sense, but we'd maybe have to try it and see how it played out. I don't know what fltk2 did here. Would the fltk2 approach be informative here? Would using pointers in place of indices allow us to leverage themes and such, for example? > - keystrokes are encoded in 16 bit, but Unicode may need 24 bits and more > - shortcuts are still ASCII only - they should be USC4 plus modifier. Though shortcuts probably need to map to single keyboard keys, as I guess a composed key would be hard to use as a shortcut, and languages that are entered via Input Methods probably can't use the IM to trigger shortcuts. So, I guess what I'm saying is that, in practice, the keystrokes are limited to what's on the physical keypad, which is probably going to be a small number... Though once the key is in the system, I guess it does need to be in some Unicode encoding (utf8 rather than usc4 though, perhaps?) > - what about events and their parameters? How can we add user events > and their parameters? We will need that if we want to support multitouch > and gestures. Multitouch would be great, I think, but I don't know how we do that. How much of that do we do in fltk, how much on user-space, how much can we count on the OS to do for us... And if we depend on the OS, how is that going to work cross-platform. To make it work cross-platform do we have to do more of it in fltk so that we don't have to worry about the disparate levels of support across the different host platforms? Also, for multitouch, I assume we mean multiple touch-points being fed to the one app (not multiple touch-points to multiple apps at the same time, one at a time...) -- Ian _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
