Black background when height > 30000

[turdparty]

Hi,

I ran into an issue that seems easy to reproduce. The problem is that the background of a vbox or box gets painted black when its height is large. 30000 pixels for instance. 3000 still displays fine. This ignores any background-color style or other options, as far as I could tell.

To reproduce simply create a new openfl haxeui project, like so: haxelib run haxeui-core create openfl Then open main-view.xml and add <vbox width="100%" height="30000" style="background-color: green;"/> below the buttons or something. Then run using openfl test html5.

I'm using openfl 9.1.0 and git versions of haxeui, slightly behind on commits. I found it because I added 200 items to a tableview, which is slow, but I would expect more people to have run into this. So maybe I'm missing something.

[ianharrigan]

Could this be some limitation of openfl? I mean, if you create a 30000x1000 sprite in openfl, do things go wrong?

I found it because I added 200 items to a tableview, which is slow

FYI, tableview can be "virtualised"

[turdparty]

I've created an openfl project and tested both a sprite and bitmap with 30000 height, without issues.

bitmap.height=30000;
graphics.beginFill(0x00FF00);
graphics.drawRect(0,0,300,30000);
graphics.endFill();

You can paste that into the code generated by openfl create DisplayingABitmap. May want to replace the png with a gradient for clarity.

Perhaps it is related to styles in some way? But height shouldn't make a difference though...

(Thanks! Is there info on virtual tableviews? I'll look into it for sure.)

[ianharrigan]

Is there info on virtual tableviews? I'll look into it for sure.

I thought there was an example in the component explorer, but there isnt, so ill make a note to add one, but really all you need to do is add "virtual=true" to the tableview and it should work with millions of items now... One thing to be aware of is that, with virtual tableviews (or listviews) the item height must be consistent

[turdparty]

Is there info on virtual tableviews? I'll look into it for sure.

I thought there was an example in the component explorer, but there isnt, so ill make a note to add one, but really all you need to do is add "virtual=true" to the tableview and it should work with millions of items now... One thing to be aware of is that, with virtual tableviews (or listviews) the item height must be consistent

Ah, that would be an involved change for us because we have user-created comments in some table fields. But regardless, it's a good option to have, thanks!

[ianharrigan]

FWIW, at some point when i have some time, im going to revamp (or rewrite) tableview, as ive found a number of issues with it personally too. Some are quick wins, but others a little more involved.

[turdparty]

FWIW, at some point when i have some time, im going to revamp (or rewrite) tableview, as ive found a number of issues with it personally too. Some are quick wins, but others a little more involved.

Oh that's good news! Yeah there are some things.. I think the horizontal scrollbar in the tableview doesn't scroll the header, just the items for instance. But that can be circumvented. The tableview is decent enough. I'm a lot more worried about the black background :)

[ianharrigan]

well, i just ran:

<vbox width="100%" style="padding: 5px;">
    <button text="Huge Component" />
    <vbox width="100%" height="30000" style="background-color: red;" />
</vbox>

Worked fine on windows (hxcpp), but black box on web, looking in the console:

Maybe the reason it worked normally is because the its a bitmap? (not sure that it is). Or because the width is 300, not around 2000?

EDIT: whats the usecase for this anyway? I mean, 2000x30000 is a pretty huge component by any standards.

EDIT 2: looked up max texture sizes and its says:

2048 or 4096 seems to be reasonable limits. At least as of 2020 it looks like 99% of devices support 4096 but only 50% support > 4096.

[ianharrigan]

btw, i get a similar issue (though it white, not black) with:

        var s = new Sprite();
        s.width = 300;
        s.height = 30000;
        s.graphics.beginFill(0xFF0000);
        s.graphics.drawRect(0, 0, 300, 30000);
        s.graphics.endFill();
        addChild(s);

Without haxeui, i get the feeling that its just not realistic to try and create a 30k height texture in openfl (or webgl)

[turdparty]

Alright. I don't know how openfl / haxeui do their rendering. This did not start out as an issue with a sprite with 30000 height.

The component that was large in height was a tableview. To circumvent a scroll issue I disabled the vertical scrolling of the tableview and put it in a scrollview. Thus the tableview uses its full height. And the scrollview has its box around the tableview which now contains a very high component, thus starts drawing a black background.

And I think I get the issue in the tableview itself as well. Because it is a scrollview with a box. I'm sure I tried it... Otherwise I'll switch to the table header not scrolling bug.

[turdparty]

I think this can be closed. I don't seem to have the bug when I remove the scrollview around the tableview and set the tableview height explicitly. So I'll switch and deal with the header.

[ianharrigan]

Otherwise I'll switch to the table header not scrolling bug.

Care to elaborate on this issue?

[turdparty]

If you create a tableview with a certain height and width, and then add a header with a bunch of columns longer than the width you can scroll the tableview horizontally. But the header will not scroll. Thus the header no longer matches the columns/contents.

[ianharrigan]

You sure: http://haxeui.org/builder/?ehcauw ?

You might want to update haxeui... i seem to remember a (pretty recent) bug around this...

[turdparty]

Thanks! It was a commit made on 13 september. One day after I last synced I think :) So there's no problem with the header.

Virtual also is a nice possibility. I don't notice anything with 200 items, both versions are pretty slow imo. But, with 2000 items the normal version won't even fully load. It does show the tableview, but no interactivity like mouse hover color change. Then the safari browser on my mac from 2019 decides to reload the page :) Doesn't happen often. However, if I set virtual to true, the tableview is about as quick and responsive as the 200 items version. Which is amazing. So thanks for adding that!

[ianharrigan]

Yeah, there are defo issues with tableview, though im a little surprised that virtual isnt pretty instant with either 200 or 2000 or 20000 - ill have to check it out. Im in the process of speeding things up at the moment so now is probably a nice time to see if there are little wins in the openfl backend (ive found a new way of measuring text in haxeui-html5, and its sped up non virtual tableviews 3-10 times!)

[turdparty]

Oh that's good news, speed increases would be great! Even 2 times the responsiveness would help a lot.

On 10/6/22, Ian Harrigan @.***> wrote:

Yeah, there are defo issues with tableview, though im a little surprised that virtual isnt pretty instant with either 200 or 2000 or 20000 - ill have to check it out. Im in the process of speeding things up at the moment so now is probably a nice time to see if there are little wins in the openfl backend (ive found a new way of measuring text in haxeui-html5, and its sped up tableview 3-10 times!)

-- Reply to this email directly or view it on GitHub: https://github.com/haxeui/haxeui-core/issues/482#issuecomment-1270052816 You are receiving this because you modified the open/close state.

Message ID: @.***>

[ianharrigan]

So, ive made a few changes to tableview (and openfl backend), id be interested to know what (if any) effect they have on your test app... keep in mind there is no silver bullet here - im creating a table of 200 rows and 20 columns, each of the columns randomized as to pretty must ensure they wont be the same... in my preliminary testing i see about a 10% improvement. So still some distance to go, but these things add up.

There are some fairly simple chances in git core, but, i think a pretty important change in haxeui-openfl. however, currently this is hidden behind a flag cache_text_metrics, so you'll need to -D cache_text_metrics. Id be interested in your results :)

[turdparty]

I'm having some trouble testing. The first try worked fine, it was a little faster I think. But after switching back and forth to compare the tableview's speed it seems to ignore the flag and the tableview no longer updates while scrolling. Which is what I get when I don't use the flag.

I did clean and rebuild. Not sure where the issue is...

[ianharrigan]

VSCode issues maybe? Does it work consistently via command line?

[ianharrigan]

tableview no longer updates while scrolling

Can elaborate on this? I did make a change where the layout was being constantly invalidated while scrolling, but i dont get why that is a problem.

[turdparty]

I always use the command line to run. Right, I mean the contents of the tableview shows no visual change when scrolling. The vscroll does move.

But, the weird thing is, I tested the changes on another app, and they seem to work fine, wether I set the flag or not. So problem solved I guess :D

I believe it's a bit faster now, thanks!

[ianharrigan]

Right, I mean the contents of the tableview shows no visual change when scrolling. The vscroll does move.

im confused, is this happening still? It shouldnt be. Can you .gif it or something as im a little lost now. :D

[turdparty]

Apologies for the lack of clarity. Somehow, the error occurs in my test program. But it's probably a weird caching error or something.

But in my main program it works without any errors. So I'm good. I think this is a good addition. I'll give you a heads up in case I run into the error anywhere else.