Haxe

i think it would be nice to not have to disable batching though... iirc correctly we did speak about it, and having some type of callback (type) think seemed to make the most sense

Yes. To make sure things are z-ordered correctly, you probably have to render the already batched things (as I assume currently happens at the end of the frame), call the callback, continue batching

_Or_ have some API where I can tell it 'render this image here', so that it doesn't 'interrupt' batching, though that gives less flexibility than just a space to use Kha's rendering stuff.

so what if, as a test, you override "renderStyleTo"?

Ah, hm, interesting. So I write override the batch processing/rendering thing? I don't know what `renderStyleTo` does right now.

```
private override function renderStyleTo(g:Graphics, c:ComponentImpl) {
    super.renderStyleTo(g, c);
    // do other things here
}
```

what does the colour picker code look like? Draws and image?

renderStyleTo will be called differently depending on if batching is on or off

right, but i think g.drawImage will break batching there

in fact... i think that function isnt batch friendly, right?

Ahh. I was only thinking of the haxe ui side, not kha. I'm an idiot 😆

maybe im wrong about that? But i thought text, images and pixel operations needed to be grouped to help the batcher

Yes, you're right, drawing an image and then drawRect etc will cause new draw calls.

so i _guess_ what you could do, is override renderStyleTo and draw the circle, rect there and override renderImageTo and drawImage there? Dunno if that will work though with regards to z-order, so might need some other calls

Na, I don't think I can fit this in with batching. Surely though the rest of the UI can be batched? I tell it to render what it's batched so far, I render my things, it continues?

yeah, that defo sounds like a bug.. i mean, OK, your code breaks the batching, but i would expected (assumed) that haxeui will just carry on regardless

I think what happens is it renders, but because batching 'delays' the UI rendering, it draws on top of the colour picker.

I may have to use renderdoc to see how frame rendering progresses

so, as a test, what happens if you override renderStyleTo instead

Nothing, but I might be doing something wrong. I've just changed renderTo to renderStyleTo, adding c argument, and added c argument to super call?