The desktox from viluon

Improve :render_to_window()

The rendering method should support partial renders (with start/end process values, :cook_lines() already has those!) and shaders (custom colour lookup).

Fix Transparency Resolution Ignoring Parent's Transparency to Other Colours

Quite a complex name for the issue. The problem occurs when a buffer is transparent to one kind of colour (background/foreground) and the parent has that colour set to be transparent to the other one.

Example

This code

local buffer = require "desktox-buffer"

local w, h = term.getSize()
local terminal = term.current()

local main_buf   = buffer.new( 0, 0, w, h )
local layer1_buf = buffer.new( 2, 2, w - 4,  h - 4,  main_buf   ):clear( colours.red,   -2, "X" )
local layer2_buf = buffer.new( 2, 2, w - 8,  h - 8,  layer1_buf ):clear( colours.green, -1, "X" )
local layer3_buf = buffer.new( 2, 2, w - 12, h - 12, layer2_buf ):clear( colours.blue,  -2, "X" )

layer3_buf:render()
layer2_buf:render()
layer1_buf:render()

main_buf:render_to_window( terminal )

produces

The X characters of the middle buffer (the one with blue background) should be red, but are black instead.

The Fix

The transparency resolution part of buffer:render() has to be rewritten so that instead of just looking at the relevant foreground/background entry of the parent pixel, it keeps track of "redirections" resulting from transparency values.

I am unsure as to whether or not to move the functionality for transparency resolution to a different method, #2 would benefit from this, but render() would be slower due to the extra function call.

Optimise Transparency Resolution

It could be possible to rewrite the transparency resolution logic in :render() and :cook_lines() to use a single loop for resolving all three pixel properties. After all, the coordinate repositions are duplicate code. We could determine three flags marking which properties need resolution before the loop starts, and then break once all three are falsy. Should theoretically speed things up as well as minify the code!

Implement :scroll_horizontally()

Implement :scroll_horizontally()
Rename :scroll() to :scroll_vertically() (:scroll() should default to :scroll_vertically(), however)
Add aliases (like :scroll_hor(), for example)

Allow Diverging Render and Transparency Targets

It would be really cool if a buffer could render to another buffer while pulling transparent pixels from yet another buffer - it's not even that hard to implement!

Implement in :render()
Implement in :cook_lines() and :render_to_window()

Avoid max() Function Calls

max() function calls can be easily avoided, the check isn't that long to type.

Implement Colour Mapping

Currently, one can only :map() the buffer with a function. Allow passing tables for mapping colours only.

Implement Draw-time Transparency Resolution

Render-time transparency resolution has its use cases, but draw-time transparency is a must-have feature. It avoids having to use a secondary transparent overlay buffer to use transparency features and thus has a potential to improve performance by miles.

Branch buffer off to buffer-dtt
Implement draw-time transparency resolution in drawing functions
Implement non-resolving :render methods
Make DTT available with buffer:import()

Use Doubles for Pixel Representation

Profiling has shown possibilities for an increase in performance and a major decrease in memory usage when using doubles instead of tables for pixel representation. Certain checks, such as the recently implemented (but not yet pushed) #14 are no longer relevant, as generated doubles are actually equal if their "arguments" are equal. Doubles also mean much less stress on the garbage collector.

This change means a major overhaul of desktox.buffer. To fix #10, we will actually only need to implement a small set of :import()able methods. Buffers will be able to act both in pixel-perfect and terminal ways, and will easily switch between the two without any constructor calls.

Fix :render_to_window() Ignoring Transparency

render_to_window will use raw colours from the colour_lookup table, ignoring transparency.

Transparency resolution functionality should really be included in buffer:cook_lines. This is not an issue as long as only parent buffers are drawn to windows, since those generally don't use transparency, but if you'd like to render a child buffer to a window, it should use data from its parent instead of the transparent colours and characters (which will likely cause a crash when term.blited to screen).

The relevant code as of fbf00b9 is here.

Optimise :render_to_window()

The :render_to_window() method and its base, :cook_lines(), have numerous performance issues.

Use tables for concatenating per-line data (table.concat() will perform faster) (in :cook_lines())
Use separate local variables for line data (instead of the line table)
Avoid ipairs()

Optimise :scroll()

The :scroll() method could be optimised to either avoid using table.remove()/table.insert() or use these functions more efficiently.

Desktoxin

Desktoxin is a markup/style sheet language for Desktox GUI layouts.

Syntax

-- Lua-like comments

-- Desktoxins can be injected into each other 
inject "orange_button.dtxin"

-- Styles are essentially style sheet classes
style blueish {
  background_colour = light_blue;
}

-- 'for' says what is the basis of this style, i.e. what element
-- you actually get from the constructor
style blue_button for button {
  background_colour = blue;
  foreground_colour = white;
}

-- Anything that isn't a style is a part of the document itself

-- Names are used for reference in Lua code
blue_button "button1" {
  x = 5;
  y = 4;
  width = 12%;
  height = 3;
  text = "Foo";
}

-- blueish did not specify the parent element, therefore
-- it has to be used explicitly
button blueish "button2" {
  x = 0;
  y = 0;
  width = 1;
  height = 1;
}

list_view "my_list" {
  x = 50%;
  y = 0;
  width = 50%;
  height = 100%;
  -- Arrays are defined in [square brackets]
  children = [
    -- Any number of styles can be applied to
    -- an element. They will be used in the
    -- order they are listed in, the next one
    -- always overriding the previous one.
    -- Values that do not cause a clash
    -- will be kept
    blue_button blueish "button3" {
      x = 0;
      y = 0;
      width = 100%;
      height = 3;
    };
  ];
}

Implement Pixel-perfect Buffers

Branch desktox.buffer and desktox.buffer-dtt off to desktox.buffer.pixel-perfect and desktox.buffer-dtt.pixel-perfect, respectively. These buffers should only use a single number for each pixel, and have shrinking render methods for rendering to terminal buffers.

Generalisation

To avoid duplicate code, utilities for shrinking and (perhaps) transparency resolution should be moved to a common library.

Adopt Continuous Integration

We need CI with proper tests and performance reports for all modules. I'm thinking Gitlab CI (wanted to move/mirror the repo anyway).

Optimise Full Transparency

It could be feasible to keep a single "fully transparent" pixel, that we could compare against in the render methods. It's just an if per draw call, with three comparisons, so the performance impact is probably negligible. The comparison in render methods would avoid (best case scenario) 3 table accesses (caching the pixel contents) and render-time transparency comparison. Worst case scenario, it would avoid 2 comparisons done at render time (3 transparency values, minus the == for the pixel itself). Note that when #11 is resolved, the parent == target check should go next to this pixel comparison.

Implement API Configuration

I've always wanted to have a desktox.cookAPI() function, which could transform the API into camelCase or TitleCase at will. In fact, one of the main reasons for snake_case was that it can be converted into other naming conventions easily and without clashes.

But we could do even more. Today on Gitter, I shared a rather interesting idea. There are multiple approaches to many of the existing methods of desktox.buffer, and more will probably arise over time for this module as well as for the other ones. Each approach suits a different scenario. Shipping these alternative functions with Desktox (either included within the module or separately) could then provide the users with heavily optimised tools that suit their use case best. Desktox could determine the best function to use (at library load time) by itself. Alternatively, the user him/herself could specify which implementation to pick for the buffer/handler/whatever _methods table.

Implement :shrink()

Implement a method for shrinking a buffer using the teletext characters of CC 1.76+.

viluon / desktox Goto Github PK

desktox's Introduction

desktox's People

Contributors

Stargazers

Watchers

desktox's Issues

Example

The Fix

Syntax

Generalisation

Recommend Projects

Recommend Topics

Recommend Org