What I am saying is that a good support of low level graphic is usually necessary to be able to build high level stuff (=components) that are appealing. For instance, if I take the example of an OnOffSwitch component, even if it is quite a simple component in its composition (it is just two elements: a track and a thumb), if you want to apply some transparency to the global component, you need to support porter-duff alpha composing operations. Indeed, if you draw a semi-transparent thumb on top of a semi-transparent track, with the default "src-over" operation, you will see the track under the thumb. So you need to support the "src" operation so that, when painting the tumb, the track behind would be erased by the pixels of the thumb covering it. This is just an example and the support of porter-duff operations can be really usefull when you start to compose components a bit complex. So, OK, spending time improving the low level graphics may not seem a priority for the default CN1 user/client but I think it is worth it. The time you would have spent developping support of low level graphics would be rewarded a 100 times when you will developp higner level stuff (by easing the devlopement of complex components or alowing you to implement subtle graphic rendering that makes all the difference). The support of low level graphics can even have direct benefit to the standard CN1 user like the case of color transforms that I mentionned previously (beeing able to have all the icons of your app as greyscale image assets and to color them on the fly to match your theme is really convenient and much more poverfull than the support of fontimages that users already took as a great step forward I think) As for the impact of low level stuff on the CN1 traction, I think you are underestimating it. Experienced developpers that might be attracted to try CN1 probably don't take the plunge because they saw UI capabilities of CN1 are quite limited compared to the alternatives for the moment. As for default users, they are probably mostly convinced by the showcase section of a Framework. They mostly base their choice on the "Wow" effect of the few apps they may have seen developped with this Framework (even if they don't necessarily need to achieve the same UI level in their app). So you just need a few developpers using the full capabilities of your Framework to create beautifull apps to gain a lot of traction. But like I already said, it is really difficult if the set of Tools at their disposal is limited ;) Bytheway, apps are using more and more graphical effects that where previously only used in games (2.5D for components with light effects and shape/color transform animations, 3D for augmented reality, non rectangular components with custom shape clipping and so on...) so closing the gap beetwin game developpement frameworks and app oriented frameworks in terms of low level graphics support make a lot of sense in my opinion In what concerns porter-duff most speciffically, fully supporting it might not even be that complicated. Most targeted platforms already support it natively (Android, IOS, HTML/javascript: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/globalCompositeOperation (even if I didn't implemented it yet personally as I don't target javascript)) and the most problematic target is actually JavaSE wich has a limited support with AlphaComposite on awt graphics (but that requiere the graphics to use ARGB color encoding which isn't the encoding used by default). But libGDX (yes I know it is a gaming Framework ;) ), which target the same platforms as CN1 has a full support for it so it must be possible.
On Tuesday, September 25, 2018 at 7:30:14 AM UTC+2, Shai Almog wrote: > What I'm saying is that this doesn't get tested because these features are > used mostly for things like transitions in "non-gaming" cases. If you don't > use the component model you are walking a path that most of the existing > users don't tread so you'll run into bugs. > > When I said UI I meant good design by default. Mostly high level stuff > such as the Picker component, on-off-switch and default native themes. > While I agree it's nice to have good low level graphics I don't agree that > this is a high priority. If I'd invest time in low level graphics I'd > invest it in a Metal rewrite of the OpenGL iOS code, not in additional > features. Either way none of this is something that's actively keeping > users away. The look & feel of the default applications/builtin widgets is > something that impacts our traction far more than low level stuff. > > I think porter duff would be nice, but we need to run on iOS, Android, > JavaSE, UWP & JavaScript. And still be performant... Since modern UI's are > mostly flat and "simple" I'm not sure how important that would be for the > typical developer using the system. Something far more important would be > on-device-debugging which we have in prototype but don't have the > time/resources to bring to production. > -- 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 codenameone-discussions+unsubscr...@googlegroups.com. 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/eac069c3-92c3-4407-a376-b0625fb07614%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
