You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setting the _bytesPerLine really high (in my case > 1000) results in a severe performance degradation. There is no performance loss when trying to set _bytesPerLine = 1 so everything is put into one column, instead of just one row.
My reason for this is that I want to enable the editor for other kinds of data representation - for example, I want to load an image but keep the spatial dimensions of the image in the editor (n rows, m columns).
So far, this editor is a great piece to work with!
The text was updated successfully, but these errors were encountered:
I'm struggling to understand why there is decrasing performance when increasing the bytesPerLine. I understand that for rows only the visible ones are drawn but there seems to be no such consideration for cols/ bytes per line. Well, I will try to adapt and upload something.
I think you're right. For lines it is calculated exactly which lines are visible and renderable. Such a mechanism is missing for columns. I didn't expect the use case to show so many columns. That's why many columns render a huge area unnecessarily.
Setting the _bytesPerLine really high (in my case > 1000) results in a severe performance degradation. There is no performance loss when trying to set _bytesPerLine = 1 so everything is put into one column, instead of just one row.
My reason for this is that I want to enable the editor for other kinds of data representation - for example, I want to load an image but keep the spatial dimensions of the image in the editor (n rows, m columns).
So far, this editor is a great piece to work with!
The text was updated successfully, but these errors were encountered: