Hey! Thanks alot for the work on this!
I will test it as soon as i get the time today, and let you know how its looking!
As for compiling to Android - i did nothing special, just used
kha\make android-native --compile --debug --arch arm7
… But i think you have to use the git version of kha… The one in haxelib is old…
Hi!
So did get to test it finally! 
It works much better than before now! Great!
-The scaling issue seems gone, and the graphics are sharp like they should! Fantastic!
-The scrolling works also now like it should - yey! (But should the scrollbar be visible?)
-Setting some items using style=“width:100%;height:100%” seem to work now! But not the top level element - using style to that there doesnt seem to work yet!
I’ve only had time to test using a very basic test app so far, but will continue to test things!
Looking very good so far! (Screenshot from the app on my S10+)
Perfect, so yeah, its not 100% done yet, but all the things you mentioned are the things i thought would have been fixed, and the other are the things i thought wouldnt have… so thats good!
Ill look at the others tomorrow, the 100% one is interesting, and possibly a bug in haxeui-kha in general, the scrollbar being visible is that “mobile” style isnt being added automatically (as it is in openfl), ill check that out also… you could do <scrollview styleNames="mobile" /> for now while i look into adding that by default for android builds.
Cheers!
Ian
If you pull latest from git a try again, any improvement? Wrt to the 100% issue, can you paste any code? Seems strange it doesnt work.
Cheers!
Ian
EDIT: what happens if you dont use <box style='width:100%'> and instead use <box width="100%">? It should be the same, but maybe there is a bug there.
Hey. So trying the latest from git it does not fix it… With style=‘width:100%’ it seems the top element aligns as if the size is zero… check the screenshot. Its also however exactly the same bug on HTML5 - desktop.
Note that if i use width=“100%” it works just fine! Its just with “style”
hang on… so width=100% as a property on the top element works, but it doesnt work when you use it as a part of a style attribute?? Ie:
Works:
<box width="100%">
Doesnt work:
<box style='width:100%'>
???
Yes correct. The result is the same both on mobile and html5 (did not get a chance to test other targets yet).
Are you not getting the same results in your testing?
Is it related to this perhaps ?
I hadnt tried using the style values, which i will do later. I was pretty sure it wouldnt have been an issue as they should do the same thing, but clearly dont! It may very well be something related to that issue above, its weird though as other backends dont exhibit this behavior and it should be the same code really. I do have a preliminary thought of what it could be - ill test it out later.
Thanks!
PS: did the scrollbars work themselves out on latest haxeui-kha (git)? It should automatically add the :mobile psuedo class now.
Ok, cool! Yes, looks like the scrollbar is correct now!
Hm… So i’ve found a new issue here… regarding ListView on Kha-mobile…
It seems for whatever reason that the performance is -really- bad.
A simple list with 100 items runs very slow, and if i put in an itemrenderer with a box and two labels
the performance drops to something like 3-4 fps… Any idea?
[Edit: seems performance is also an issue with adding many items to a scrollview, although not as bad… But it makes me wonder if its really realistic to use this at all to build a mobile app… Kha is quite performant usually so i would have thought this would have worked a bit better…Maybe its related to how components are drawn… Any thoughts? ]
Hmmm… can you set “virtual=true” on the listview? Though 100 items certainly doesnt sound like alot so shouldnt really need anything like that. For good measure can you zip up your application (assuming its a test application) and attach it so we are talking about the exact same thing.
Ok, so using virtual=true gives me a significant boost, especially with the item renderer… The speed on a simple list and with an item renderer seem similar now… That being said - its still choppy …maybe ruinning at 20-30 fps… on an Samsung Galaxy S10+
Test project here:
Thanks - looking at this now - 100 items really isnt enough to warrant having to use a virtual listview (its for 100,000’s or millions), so something is up.
Cheers,
Ian
Interesting, its the drawing of the text that is slowing it down LOADS… Still investigating it, but if i remove any of the kha “drawString” calls its totally fine
Hm… That sounds strange. Looking at the kha source code the drawstring is building a buffer with a quad pr letter - and this is drawn together with other stuff… pretty standard way to do it… But if thats right it means there’s only one drawcall to the GPU, with just a few quads… So there should be no way that alone would cause a slowdown like that… Sure its not related to layout or something being drawn multiple times?
[Edit : Did some isolated tests with DrawString, see screenshot - running smooth at 60fps here… ]
Yeah, its weird, for sure… but if you comment out this line: https://github.com/haxeui/haxeui-kha/blob/master/haxe/ui/backend/TextDisplayImpl.hx#L128
Everything feels alot faster (but of course, no text now), i wonder if its in combination with a glScissor or something…
Hm. Well using g.scissor helps with performance… But still… Clearly Kha can render lots of drawStrings without a big performance loss, so that alone cant be the reason the app slows down so bad… I can try to do more testing here…
Yeah, im certainly not arguing that kha cant draw 100 strings on the screen, but at the same time if you comment out that line things go “back to normal” so the way haxeui is drawing strings is doing something strange, but i honestly cant think what… is your test app (non haxeui) drawing strings every frame in in the render loop?
Cheers,
Ian
Bit of an update from IRC:
are you mixing rendering of rects/images (for bgs/borders or some such) and strings? maybe try to comment out haxeui-kha/haxe/ui/backend/ComponentImpl.hx at master · haxeui/haxeui-kha · GitHub and see if only rendering strings is fast
And indeed it does make things fast.
so whats the issue with mixing drawing rects and strings?
it uses different shaders so it can’t be batched by g2
Looking for a solution now, but looks like we’ve found the issue! 
Aha. So the number of drawcalls goes up way because of this. So the solution is either to use a custom shader or even better group all similar drawcommands and draw them together all at once. Then it should be able to be one drawcall pr type and hopefully fix the issues… Will it be possible to do? Depends on way haxeui does layout and drawing?
