| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2175
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | why does not FLTK support framebuffer directly? |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | Jern |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | None |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | Jern
19:33 Mar 16, 2009 |
| why does not FLTK support framebuffer directly? | |
| |
| #2 | fabien
11:45 Apr 01, 2009 |
| DirectFB as other graphical layers support within an adequate decoupled architecture is planned for 1.4 | |
| |
| #3 | AlbrechtS
17:32 Jan 15, 2023 |
| Currently, i.e. in 1.4.x, we can't support directly drawing to the framebuffer. However, FLTK 1.4 makes good progress in this direction, for instance drawing with Cairo in a window buffer object for Wayland.
It is possible that framebuffer support will be added in a later release, but there is no guarantee that this will ever happen.
For now I must close this STR because we're phasing out STR's since we switched to GitHub.
Questions like this one should be asked in fltk.coredev:https://groups.google.com/g/fltkcoredev | |
[ Return to Bugs & Features ]
|
| |
