[haiku-commits] Re: Padding Problem in hrev54496 align BTextView text rect?

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 6 Aug 2020 19:37:57 +0200

On Thu, Aug 06, 2020 at 12:11:08PM -0400, John Scipione wrote:

On Thu, Aug 6, 2020 at 8:57 AM Rene Gollent <anevilyak@xxxxxxxxx> wrote:

On Thu, 6 Aug 2020 at 08:52, Alexander G. M. Smith <agmsmith@xxxxxx> wrote:

I see that a new field fAlignedTextRect was added to
headers/os/interface/TextView.h and some padding was removed.  But
shouldn't the new field go where the padding was removed?  Otherwise
binaries built with the earlier headers will look for some fields
at the wrong offsets into the structure.

That shouldn't be the case, since they're private fields only accessed
by class functions, none of which are inline. As such, only the code
in libbe is accessing them, and that's been rebuilt in conjunction
with this change.

I see PulkoMandy went with the 4 byte BRect version instead of using a
pointer - that solves the 32/64 bit class size issue but now we're
down to just two more extra private member bytes. I'll have to look
into how we can extend the BTextView class to add more members. I'm
thinking of adding a BTextViewPrivate class along the lines of the
BMenuPrivate class. We'll need something like this to extend the class
further.

From a quick look, there's some space to be reclaimed by converting all
bool to bitfields and grouping them together (someone has already
started this for newly introduced ones for layout, apparently).

Moving fields around to remove padding is also an option.
When you have something like this:

int32 f1;
int8 f2;
int32 f3;

there will be 3 bytes of padding so f3 is aligned on 32bits. Grouping
smaller fields together allows to make better use of the space.

In Linux there is a tool called pahole that can report such wasted
space. I think I tried to port it to Haiku but didn't get it working at
the time, but I don't remember why that was.

Of course, the thing to take care of is keeping the size correct in both
32 and 64bit versions, which can lead to more complex management of the
reserved entries array.

-- 
Adrien.

Other related posts: