| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
This looks like an oversight from "quickly testing a potential fix" and
then forgetting to make a production-ready when it works.
https://bugzilla.gnome.org/show_bug.cgi?id=755691
|
| |
|
|
|
|
|
|
|
| |
Statistics for the gtk3-demo listbox example show that the
vast majority of calls to _gtk_allocated_bitmask_resize go
from a size of 2 to 2. Don't needlessly call realloc() in
this case.
|
|
|
|
|
| |
The functions was written in a way that would possibly
resize the mask twice, which is not necessary.
|
| |
|
|
|
|
|
|
|
|
| |
The speed-up in 7da1f8a1ce145f48b6299fd8be86a64389ff0b0d was wrong in
certain conditions, even though it didn't trigger the existing
testsuite.
New testcase /bitmask/invert_range_hardcoded included.
|
|
|
|
| |
It was showing up on profiles and has a comment asking for speed.
|
|
|
|
|
|
|
|
|
| |
We were doing the wrong thing *and* writing uninitialized memory while
doing so. BAD.
Also added tests exposing these.
https://bugzilla.redhat.com/show_bug.cgi?id=1185585
|
|
|
|
| |
Code taken more or less verbatim from CoglBitmask.
|
|
This does nothing but turn all GtkBitmask functions into static inline
functions that call the gtk_allocated_bitmask_*() equivalent.
The implementation of the static functions has also been put into a
private header, to not scare people who want to see how things are
implemented.
|