Yeah, im playing with a 2 pass system now, once for styles and another for texts - not sure how its going to work with overlapping controls though…
so, btw, there is an experimental/batching branch on haxeui-kha… its of course just a test / experiment at the moment, but i would be interested to know what your results are, for me its perfectly usable, and could also be improved further ALOT, but its a start. Looks like the rendering in haxeui-kha needs to be totally rethought! 
Cheers,
Ian
Right, ok i tested it now!
Well, the performance of the item renderer is better! I would say its more or less the same now with virtual on or off … And thats really good!.. But not that big of a difference for a simple text list… i still feel it is not very smooth though… the scrolling is a bit choppy … as was the case before also (with virtual=true). So its definitly better but still hope it can be improved, yeah 
Oh, really? For me simple list view works just fine:
<vbox style="padding: 5px;" width="100%" height="100%">
<listview id="lv1" width="100%" height="100%" virtual="false">
</listview>
</vbox>
class Main {
public static function main() {
var app = new HaxeUIApp();
app.ready(function() {
var main:Component = ComponentMacros.buildComponent("assets/main.xml");
app.addComponent(main);
var lv = main.findComponent("lv1", ListView);
var ds = new ArrayDataSource<Dynamic>();
for (i in 0...100) {
ds.add({
value: "Item " + i
});
}
lv.dataSource = ds;
app.start();
});
}
}
Does this apk work slow: http://haxeui.org/shared/app-debug.apk
Can you share your apk also?
Cheers,
Ian
EDIT: and yeah, there is loads of room from improvement, just threw together this test / experiment to see what it behaved like,
Ok, tested your apk - it doesnt have inertia enabled so its a bit harder to see - but there’s definitely stuttering going on when scrolling here… Try with my test apk?
OK, nice one… yeah, defo still a little choppy on my phone - so thats good (ie, we have the same issues), there are a load of optimizations i can make here, for sure (like not trying to draw items that are “offscreen”)… Well, ill have to let a “solution” sink in for a bit, but still, getting there!
EDIT: one final thing, what does your item renderer xml look like?
1 Like
Its just a simple test:
< itemrenderer width=“100%”>
…< hbox width=“100%”>
…< label width=“40%” id=“value” verticalAlign=“center” />
…< button id=“button1” text=“Button1” width=“30%” />
…< button id=“button1” text=“Button2” width=“30%” />
…< /hbox>
< /itemrenderer>
1 Like
OK, one final final thing 
Are you sure you are using the experiments/batching branch of haxeui-kha? latest haxeui-core from git? How many items are you adding? My version is still pretty fast and im using your itemrenderer.
Cheers,
Ian
Yeah, definitely using the latest git version. I’m adding just 100 items.
Can i try the apk from you to compare perhaps?
So im testing some things here and i found a BIG culprit…
Batching “DrawString”, “FillRect” and “DrawLine” made a world of difference.
So its not just drawString… its all… The difference between doing separate batches of all and doing fillrect + drawline at once was from 6 fps to 60!!
[Edit: sorry, typo! ]
oh? Where is drawText??? Ive clearly missed this one.
Right, where is drawLine though? I cant see that either in haxeui-kha…
g.drawLine() ? … its there in Graphics2
I mean where is that used in haxeui-kha? How have you batched that?
Oh, sorry. This is in my app - im just performance testing kha on mobile here. What i mean is obviously you cant mix any of the drawtypes to g2 if you want batching to work. The difference im seeing in my testing is huuuge…
Right, cool… this is all pretty good news… still doenst explain why we see differences in the same app and the same git code, here is my tests (100 items, your item renderer):
non virtual: http://haxeui.org/shared/app-nonvirtual-debug.apk
virtual: http://haxeui.org/shared/app-virtual-debug.apk
Huh… That is strange…
The non-virtual one is choppy - just like mine.
But the virtual one… is quite smooth…
Hmm… whats going on here…
OK, thats good though… so i think the breaking batching is one thing (this a big one i think), then some other optimizations can be made (like making certain calculations once - though i think this isnt going to save too much time), and another big one would be to no even attempt to draw things that are “offscreen”… i mean, in that example, there are 100 items, so 100 drawString calls and 100 x n drawRect calls 70ish of which be drawn offscreen, so they simply arent needed - that i think will make all listviews essentially virtual (in kha)
FYI, Robert just said this in IRC:
Yes. That said, even when you break the batch all the time, it shouldn’t make things INCREADIBLY slow. After all in basically all the other Haxe things there isn’t even any batching so it’s basically like breaking after every single call. So I suspect there’s something else going wrong in addition to the batch break - can you put your slow code in a GitHub issue?
I wonder if its also worth you opening an issue with your drawLine stuff?
Hm, it sounds like an issue for sure… But it will do some more testing first with the drawLine stuff.
It seems to only be an issue on mobile - on desktop everything is fine - batching or no batching
1 Like