► |  | GUI: PLT Graphics Toolkit

1 | Overview
2 | Reference
3 | Configuration
4 | Dynamic Loading
| Bibliography
| Index

► | 2 | Reference

2.1 | Windowing Classes
2.2 | Windowing Functions
2.3 | Drawing Classes
2.4 | Drawing Functions
2.5 | Editor Classes
2.6 | Editor Functions
2.7 | WXME Decoding

▼ | 2.3 | Drawing Classes

2.3.1 | bitmap%
2.3.2 | bitmap-dc%
2.3.3 | brush%
2.3.4 | brush-list%
2.3.5 | color%
2.3.6 | color-database<%>
2.3.7 | dc<%>
2.3.8 | dc-path%
2.3.9 | font%
2.3.10 | font-list%
2.3.11 | font-name-directory<%>
2.3.12 | gl-config%
2.3.13 | gl-context<%>
2.3.14 | pen%
2.3.15 | pen-list%
2.3.16 | point%
2.3.17 | post-script-dc%
2.3.18 | printer-dc%
2.3.19 | ps-setup%
2.3.20 | region%

On this page:

call-as-current
ok?
swap-buffers

top← prev up next →

gl-context<%> : interface?

A gl-context<%> object represents a context for drawing with OpenGL to a specific dc<%> instance. To obtain a gl-context<%> object, call get-gl-context of the target drawing context.

Only canvas dc<%> and bitmap-dc% objects support OpenGL (always under Windows and Mac OS X, sometimes under X), and in the case of a bitmap-dc%, the context is usable only when the target bitmap is non-monochrome. When the target bitmap for a bitmap-dc% context is changed via set-bitmap, the associated OpenGL context is reset, but the gl-context<%> keeps its identity. Canvas contexts are double buffered, and bitmap contexts are single buffered.

The scheme/gui/base library provides no OpenGL routines. Instead, they must be obtained from a separate library, such as sgl. The facilities in scheme/gui/base merely manage the current OpenGL context, connecting it to windows and bitmaps.

Only one OpenGL context can be active at a time across all threads and eventspaces. Except under Mac OS X, OpenGL contexts are not protected against interference among threads; that is, if a thread selects one of its OpenGL contexts, then other threads can write into the context via OpenGL commands. However, if all threads issue OpenGL commands only within a thunk passed to call-as-current, then drawing from the separate threads will not interfere, because call-as-current uses a lock to serialize context selection across all threads in PLT Scheme.

(send a-gl-context call-as-current |  | thunk |  |  |  |
| [ | alternate |  |  |  |
|  | enable-breaks?]) |  | → |  | any/c

thunk : (-> any)
alternate : evt? = never-evt
enable-breaks? : any/c = #f

Calls a thunk with this OpenGL context as the current context for OpenGL commands.

The method blocks to obtain a lock that protects the global OpenGL context, and it releases the lock when the thunk returns or escapes. The lock is re-entrant, so a nested use of the method in the same thread with the same OpenGL context does not obtain or release the lock.

The lock prevents interference among OpenGL-using threads. If a thread is terminated while holding the context lock, the lock is released. Continuation jumps into the thunk do not grab the lock or set the OpenGL context. See gl-context<%> for more information on interference.

The method accepts an alternate synchronizable event for use while blocking for the context lock; see also sync.

The result of the method call is the result of the thunk if it is called, or the result of the alternate event if it is chosen instead of the context lock.

If ok? returns #f at the time that this method is called, then an exn:fail:contract exception is raised.

If enable-breaks? is true, then the method uses sync/enable-break while blocking for the context-setting lock instead of sync.

(send a-gl-context ok?) → boolean?

Returns #t if this context is available OpenGL drawing, #f otherwise.

A context is unavailable if OpenGL support is disabled at compile time or run time, if the context is associated with a bitmap-dc% with no selected bitmap or with a monochrome selected bitmap, if the context is for a canvas that no longer exists, or if there was a low-level error when preparing the context.

(send a-gl-context swap-buffers) → void?

Swaps the front (visible) and back (OpenGL-drawing) buffer for a context associated with a canvas, and has no effect on a bitmap context.

This method implicitly uses call-as-current to obtain the context lock. Since the lock is re-entrant, however, the swap-buffers method can be safely used within a call-as-current thunk.
top← prev up next →