As part of fixing a graphical glitch in Mac Indiana Jones and the Last
Crusade, eliminate the menu timer from the Mac window manager. It's just
too unpredictable and error prone for my taste.
When loading other fonts than the system ones, they would get ID -1, not
the one from their resource ID. Even if you later registered the font
name, the old font entries would still be wrong. Another possibility
would be to update _fontRegistry when registering fonts, but sev was ok
with this way so let's go with it for now.
It does not consider the possibility of ID collisions the way
registerFontName() does, but apparently there shouldn't be much risk of
that.
- every malloc is now aligned on 16 bytes
- no need for the hidden pointers
- ct60_vmalloc() is called only once, the rest is handled
by dlmalloc (SV XBIOS' vmalloc is pretty fragile)
The create() overload of ManagedSurface that creates a
new, owned surface, previously assumed that the
_innerSurface was owned before the call was made. Thus,
when switching between sub-surface and owning surface
modes, a segfault would occur when attempting to free
the pixel data of the inner surface, which is not actually
owned by the ManagedSurface. This commit makes sure
that when free() is called, the inner surface no longer
has an active pointer to its old pixel data.
If there are unicode characters in the link, it was leading to
wrong length calculation.
Example of such link:
![Menü-Symbol](menu.png \"Menü-Symbol\"){w=10em}
The problem is that for simplicity, we are working with UTF8 in
Markdown, but still with U32String in MacTextCanvas. This led to
the string length be calculated for UTF8, which is a multibyte
encoding. As a result, we were overshooting the link parsing
and reading texts as numbers.
This is kind of a hacky solution: we convert text to U32 before
caluclating the string length
When moving the mouse through the menu bar, over a part that's not
occupied by menu items, the Mac menu class will start calling
processEvent() recursively. This is bad for two reasons: During the
recursion (which can easily reach a depth of dozens or even hundreds of
calls) there is no delay, so it will use 100% CPU. And once the
recursion unwinds, all the delays will come at once.
This moves the call to eventLoop() to after the first event has been
fully processed. Hopefully that will have approximately the same desired
effect, without any of the bad side effects.
When GLAD fails to parse version, glGetError is null and raises a
SIGSEGV.
Current version of GLAD has a bug while parsing extensions so there is a
workaround here which should disappear when it's fixed.
elasota
D G Turner
Krish
s-m33r
Matthew Jimenez
Le Philousophe
Hubert Maier
Eugene Sandulenko
Nabeel Khan
hecmar007
Torbjörn Andersson
scemino
polyesterswing
Christian Kündig
Miro Kropacek
Kaloyan Chehlarski
Scott Percival
Cameron Cawley
Matthew Duggan