Possible problems with endianess #81

New issue

Closed

opened 2014-11-14 12:32:05 +00:00 by Flix01 · 4 comments

Flix01 commented

2014-11-14 12:32:05 +00:00

(Migrated from github.com)

I'm using a little endian machine.

I was wondering if the library would still work on big endian systems (I guess I'll never use one, but my mind seems to like to create problems...).

Possible issues I can see:

Binary .fnt loading. Is that format endian free ?
The bin2c file conversion used by ImGui seems to group bytes into blocks of 4 (4 bytes -> 1 Uin32).

These problems could be solved in two ways:
a) creating all the binaries on the same machine they're supposed to be used.
b) using a more robust approach:

1. Adding code to support loading .fnt in text format (currently it's not trivial to extend the ImBitmapFont class, because it seems to store the binary .fnt blob in a single block and use pointers to access its parts.).
1. Using a different bin2c file conversion that just stores bytes one after another (producing longer source code, but the binary code size should be equal).

I don't think this is a high-priority problem [solution (a) above needs no code change], but maybe some note should be written about it...

I'm using a little endian machine. I was wondering if the library would still work on big endian systems (I guess I'll never use one, but my mind seems to like to create problems...). Possible issues I can see: 1) Binary .fnt loading. Is that format endian free ? 2) The bin2c file conversion used by ImGui seems to group bytes into blocks of 4 (4 bytes -> 1 Uin32). These problems could be solved in two ways: a) creating all the binaries on the same machine they're supposed to be used. b) using a more robust approach: - 1) Adding code to support loading .fnt in text format (currently it's not trivial to extend the ImBitmapFont class, because it seems to store the binary .fnt blob in a single block and use pointers to access its parts.). - 2) Using a different bin2c file conversion that just stores bytes one after another (producing longer source code, but the binary code size should be equal). <b>I don't think this is a high-priority problem</b> [solution (a) above needs no code change], but maybe some note should be written about it...

ocornut commented

2014-11-15 11:55:08 +00:00

(Migrated from github.com)

Hello,
I am hesitant to look into a problem before we have an actual use case, aka someone trying to use ImGui on a big-endian machine.

I don't know!
That could be fixed. Currently using ~11 ascii bytes per 4 bytes. Naively expanding to single byte would cost ~20 ascii bytes per 4 bytes. Would grow imgui.cpp by about 12K bytes. Could use a macro to keep it small. I'd prefer keeping the binary format, it's optimal to store and parse, and b) is fixable.

There's no "need" to extend the ImBitmapFont class since it is meant to load that specific format. Why I might end up with is a way to load TTF via stb_truetype and still support Angel bitmap format as well.

For now I'd rather close this to focus on important stuff, add a "Support big-endian" in the todo list. If someone shows up with that need they or us can find a solution. Unless you are feeling like investigating this on an actual big-endian architecture I'd close this and we can reopen in the future.

Hello, I am hesitant to look into a problem before we have an actual use case, aka someone trying to use ImGui on a big-endian machine. 1) I don't know! 2) That could be fixed. Currently using ~11 ascii bytes per 4 bytes. Naively expanding to single byte would cost ~20 ascii bytes per 4 bytes. Would grow imgui.cpp by about 12K bytes. Could use a macro to keep it small. I'd prefer keeping the binary format, it's optimal to store and parse, and b) is fixable. There's no "need" to extend the ImBitmapFont class since it is meant to load that specific format. Why I might end up with is a way to load TTF via stb_truetype and still support Angel bitmap format as well. For now I'd rather close this to focus on important stuff, add a "Support big-endian" in the todo list. If someone shows up with that need they or us can find a solution. Unless you are feeling like investigating this on an actual big-endian architecture I'd close this and we can reopen in the future.

Flix01 commented

2014-11-16 08:45:50 +00:00

(Migrated from github.com)

Unless you are feeling like investigating this on an actual big-endian architecture I'd close this and we can reopen in the future.

Agreed: my main purpose was just to address a possible issue.

> Unless you are feeling like investigating this on an actual big-endian architecture I'd close this and we can reopen in the future. Agreed: my main purpose was just to address a possible issue.

ocornut commented

2014-11-16 10:43:21 +00:00

(Migrated from github.com)

It's a fair issue! I added a reference to the bug number to the ImGui TODO list. Thanks.

ocornut commented

2015-08-06 14:32:13 +00:00

(Migrated from github.com)

The embedded font data now used a base85 encoded string processed byte a byte and should be working on big-endian machines.