From 211c49d23e17f11ad45c86318041b547e7bcb4b4 Mon Sep 17 00:00:00 2001 From: Scott Duensing Date: Wed, 1 Jan 2025 18:07:35 -0600 Subject: [PATCH] Added notes. --- roo_e/notes.txt | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 roo_e/notes.txt diff --git a/roo_e/notes.txt b/roo_e/notes.txt new file mode 100644 index 0000000..098c6eb --- /dev/null +++ b/roo_e/notes.txt @@ -0,0 +1,47 @@ +Roo/E, the Kangaroo Punch Portable GUI Toolkit +Copyright (C) 2022-2025 Scott Duensing + +http://kangaroopunch.com + + +GOALS +~~~~~ +Roo/E is designed to run on any platform that provides at least keyboard and +mouse input with a bitmapped display. The current mimimum target is a 486 +running MS-DOS with a VESA 2.0 compliant SVGA display. + +Unlike most low-end windowing systems, Roo/E should provide "solid" rendering +at all times. Dragging and resizing windows should not result in wireframe +representations of the window, nor should window operations interrupt or pause +the content in the windows. + +Minimized windows display a live view of the entire window contents so users +can continue to monitor their activity. + +Widgets and other window contents should instantly appear. No watching them +being drawn to the display. + +Roo/E should be thread friendly. + + +IMPLEMENTATION +~~~~~~~~~~~~~~ +In order to reach these goals, Roo/E trades memory for speed. Many surface +caches are used to reduce the amount of redraw needed at any given time. + +When new windows are defined, they specify the maximum bounds of their +content. This means no endlessly scrolling windows as is common in word +processors and web browsers. On creation, a new off-screen surface is +created with these maximum bounds. This allows widgets to be drawn in the +window without consideration for clipping. Just keep it inside the window! + +The "window manager" handles window chrome and blitting window contents to yet +another surface. This cached surface is updated when anything in the window is +"damaged". + +Finally, these chromed surfaces (or icons if minimized) are positioned and +dirty rectangles are calculated. Dirty rectangles are then merged, if +possible, to reduce the number of blits required to update the display. This +rectangle list is then blitted from the apporpriate cached surfaces to the +actual display. This results in the entire display being redrawn but with no +overdraw.