The right way to render to pixmaps is to create a GLX pixmap wrapper
and render to *that*. Almost nobody does this - including libgtkgl -
and it's almost never a problem. But it causes crashes on my system
in indirect rendering mode.
This commit changes three things.
1. OpenGL on Linux no longer requires libgtkgl, only libGL, which
comes preinstalled on many (most? almost all?) systems.
2. Rendering to pixmaps is done properly, via a GLX pixmap wrapper.
3. Direct rendering is done whenever possible, even for pixmaps.
The closure could be allocated as uninitialized memory with the
expectation that it would be filled right away, but boxing values
to put in the closure could expose the uninitialized memory to
the GC. Fix the problem by boxing before allocating closures.
On 10.9 and later, `racket/gui` now disables App Nap. Otherwise, a
program like
#lang racket/base
(require racket/class
racket/gui/base)
(define T 0.05)
(let loop ([prev (current-inexact-milliseconds)])
(sleep T)
(define now (current-inexact-milliseconds))
(define delta (- now prev))
(when (delta . > . (* 2000 T))
(printf "long wait ~a at ~a\n" delta now))
(loop now))
will start to report a wait of more than 10 seconds, as App Nap
puts the process to sleep.
Relatedly, when `racket/gui` is started via plain `racket` (as opposed
to GRacket), then it starts in "accessory" mode instead of "regular"
mode, which means that the application does not appear in the dock
or have a menu bar. As soon as a frame is shown or a root menu bar
is created, the application is promoted to "regular" mode. This works
in 10.7 and later.
The types are tweaked to match the contracts and to support passing a
list of headers to the connect procedure.
The FIXME for polymorphism has also been removed as it is now
parameterized to support "...The result of the handle procedure is the
result of call/input-url..."
This avoids mysterious errors later in the build process related to
TR and static-contracts. I don't see how the pattern-expander code
could possibly cause the errors that occur, but this commit fixes them.
Similar to the server-side problem, but on the client side. In a
game where the server drives the clients with frequent messages
through `on-tick`, per-message growth in the continuation can
matter a lot.
