On 10/18/11 11:29, Sandro Santilli wrote:
> Rob, I'll take the chance to ask: will you also find the time to fix
> the regression in framebuffer gui performance [1] ?
I was actually working on it some this week, but it's going to take
more work. The old implementation was hardcoded into the FB<->AGG
support. Now that there are proper glue files for AGG and the FB, it
needs to be reimplemented, not just "fixed".
> Since we're shipping "updates" it'd be important
> not to sell broken packs...
The framebuffer support is not enabled for all rpm and deb packages,
so this is a moot point. And we're not selling anything, this is a free
software project last time I checked... And the packages work just fine
as they are. It'd sure be nice to get comments like "glad to see
somebody bothers to keep our repository updated", rather than finding
something negative to complain about instead. In the OLPC case, this
updated package replaces Gnash 0.8.8, so it's more good news than bad.
> According to the draft policy we set in May 2010 [2] a "reasonable time"
> should be allowed for the developer breaking the build taking further
> actions. The regression bug was filed on September 07, 2011.
We're gonna have to agree to disagree on this, I don't consider it a
regression. My plan is to finish refactoring this before the next
official release. Most all the gnash developers ignores the "draft
policy" anyway, and that "reasonable time" was for critical bugs that
break builds. The lack of software double buffering when using the
framebuffer is not a critical issue. Among other things, software double
buffering is not enabled by default, so doesn't effect most builds. If
you noticed, buildbot succeeds building for all platforms. distcheck
succeeds too.
- rob -
_______________________________________________
Gnash-dev mailing list
Gnash-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnash-dev
