device rotation

[Dave Dyer]

I'm working with an android device that's designed to lie flat on a table, and it's desirable

to flip the screen orientation in 90 degree increments.  All I see in the Display api

is setting portrait or landscape.  Is the underlying functionality I need available

somewhere?

[Shai Almog]

We don't support that as even the current method doesn't work well on iOS. iOS requires view change in order to apply a runtime orientation change and that's a problem for us.

Since I'm assuming this is Android only you can probably implement this relatively easily with a native interface.

[Dave Dyer]

Thanks.  I'm also experimenting with changing it for the window only, using the graphics

transform, and I'm encountering some problems there on android devices.  I'm pretty

sure this hasn't been exercised much.

[Shai Almog]

How many transforms would we need for a tool for app development?

As I said to you multiple times before we didn't design this as a gaming platform.

[Dave Dyer]

I'm not sure I understand your question.  My app treats the entire screen as one canvas,

which is drawn into an offscreen bitmap then copied to the screen.  The alternatives

I'm investigating are using the native rotation to rotate the whole device, or use the

paint(Graphics g) method to draw the bitmap upside down.

In either case, the "gaming" aspect is incidental, it's just an application on a table,

and doesn't require particularly high performance, only reliability.   You could think

of it as a recipie application on a kitchen table, or a map application on a console

between the driver and passenger.

[Thomas]

Too be fair, a good support of graphics transforms and operations are keys to allow the creation of beautifull GUI. This is not restricted to gaming platforms. If you want to implement the material design specifications for example, you need a good graphic transform support for animations, blending mode support for correct components overlay and so on. That is why I started implementing blending modes (= porter-duff) support in my fork (https://github.com/ramsestom/CodenameOne) and I also intend to support color transforms soon (as it is a really powerfull way to handle colored icons and images, that can automatically adapt to a theme, without having to transform them into fonts or to create multiple colored version of the same image...)

You said improving the CN1 UI part is on your top priority list. Then, I really think you should start with a strong support of "basic" graphics operations as they are the basis of any UI. As, I would say, as talented as you can be, it is easier to build a beautifull furniture when you have the correct set of tools than with only a knife and a hammer... ;)

[Shai Almog]

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.

[Thomas]

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.

[Shai Almog]

I have yet to see a UI where an on-off switch is translucent or do you mean only the thumb?

It's possible to implement everything in the graphics layer but it's 100 times harder than just adding a component or making an improvement to the theme/gui builder. You need to implement it 5x in native and test it on multiple device versions, plus unit testing, regressions and performance. All the other stuff you just do in Java in the simulator.

Sure some developers notice it and it's a problem. But we don't implement low level stuff for its own reward. We implement it based on requirements. E.g. we have perspective transform which doesn't exist in JavaSE and was a hell of a problem to implement properly. We needed it to represent some effects that are common in iOS e.g. the Spinner/Picker and album cover interfaces. So in that sense it was worth adding this feature.

I look through the support and issue tracker every day, I know what people are asking for. You are arguing that we get the requests based on the product we have which is totally possible. But from my experience the "if you build it they will come" mantra is bullshit. I'd rather address the issues that are easier to address from the people who are asking for them.

E.g. in this thread you're asking for porter duff which is great, if you have a partial PR we can work to add that. But Dave is asking for something completely different and the next guy around will ask for something completely different. I'd rather put the effort into getting the damn on-off switch working properly.