[enhancement] canvas component

[malublu]

Expected Behavior

It should be a costume component avaible.

Possible Solution

Create for each target a wrapper based on there costume view helpers:

• wxWidget/Drawing/Canvas
• Android/Drawing/Canvas
• kha, openfl, flambe, .... are already drawing so simple create a wrapper sourround the draw comands.
• xwt/Drawing/Canvas
• html5

[aW4KeNiNG]

Hi @malublu .

Only FYI, you can insert any Component for each backend in a HaxeUI component. Component inherits from ComponentBase (different for each backend), and ComponentBase inherits from the minimal graphic component in that backend (or a variable, for example element in HTML5) . And you can use native methods like addChild (in OpenFL). It could work for you in the meantime.

I think that it could be useful, but it requires a common API to draw in the same way with all backends.

[ianharrigan]

I think a CanvasView would be a nice component to implement, that would use sometype of generic api that could be implemented in all backends... something like Graphics extends GraphicsBase that would expose basic operations (where possible) with things like drawLine, etc...

@malublu - what type of "costume component" do you mean? Ie, what type of visuals are you thinking about / expecting? It may already be possible with current styles.

[malublu]

@ianharrigan I mean a generic costume view. like the CanvasView. But CanvasView is a better name for it. Because that i give you a link list to the apis of all targets.

So other developers, like me, can create a costume componet library, that works on all targets. It is only an idea. But I hope it is a nice one 👍.

[ianharrigan]

I have a general idea for this, here is my outline (im only detailing openfl and html5 here, but the same idea applies to all):

• CanvasView extends Component to become part of the haxeui-core system, this in turn extends ComponentBase that lives in the backend.
  • haxeui-html: ComponentBase contains an DOMElement use as a surface
  • haxeui-openfl: ComponentBase extends Sprite to use itself as a surface
• A new Graphics class that will extend GraphicsBase that lives in the backend (as most backend type classes do)
  • Unlike most haxeui classes Graphics will take in a constructor param that is a haxeui Component, it will pass this up to the parent class (GraphicsBase)
  • Graphics will expose draw calls and simply pass them up to the parent class
• CanvasView will encapsulate a Graphics instance and use this to acheive draw calls
• CanvasView itself will be available to xml UIs, but actually drawing to it can only be done in code / script

Example Impl:

haxeui-core:

class Graphics extends GraphicsBase {
    public function new(component:Component) {
        super(component);
    }

    public function line(x1, y1, x2, y2) {
        super.line(x1, y1, x2, y2);
    }
}

class CanvasView extends Component {
    public function new() {
        _graphics = new Graphics(this);
    }

    public function line(x1, y1, x2, y2) {
        _graphics.line(x1, y1, x2, y2);
    }
}

haxeui-html5:

class GraphicsBase {
    public function new(component:Component) {
        _component = component;
    }

    public function line(x1, y1, x2, y2) {
        var context = _component.element.getContext("2d");
        context.beginPath();
        context.moveTo(x1, y1);
        context.lineTo(x2, y2);
        context.stroke();
    }
}

haxeui-openfl:

class GraphicsBase {
    public function new(component:Component) {
        _component = component;
    }

    public function line(x1, y1, x2, y2) {
        var graphics = _component.graphics;
        graphics.moveTo(x1, y1);
        graphics.lineTo(x2, y2);
    }
}

[uvtc]

I've never heard the term "costume" to describe this, but I think it would be excellent for HaxeUI to have this drawing area component.

Unless "costume" is the preferred term, perhaps change the name of this issue to "Canvas Component" to make it easier for others to find.

[ianharrigan]

Im going to close this as there are various discussions about it on the forum

(PS: i think he meant "custom" :)

[intoxopox]

Here are the sort of draw commands I'd expect. I'd bother to hand-write them here, but I've always been pretty down with AS3's graphics API https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Graphics.html There are a couple of holes in this API from my perspective, but even a subset of this would be fantastic. So I guess the most important are namely: 1) lineStyle 2) beginFill 3) beginGradientFill 4) moveTo 5) lineTo 6) curveTo 7) cubicCurveTo 8) drawCircle 9) drawRect 10) drawRoundedRect

[ianharrigan]

11. drawText

[lublak]

Therefore a separate method would be handy to query if the element has changed. However, it should also be possible to allow continuous drawing. Especially in the area of html should then rather be set to a canvas.

So a distinction should be made between

• custom element
• canvas element

Basically you can play with the idea if a SVG implementation would make sense. So custom elements could be loaded from a SVG file and accessed via "ids".

For the canvas element could also offer different drawing methods:

(3d is rather out of scope though and I wouldn't see it directly in haxeui myself.)

var context = _canvas.get2DContext();
context.drawLine(x, y);
var context3d = _canvas.get3DContext();
context.drawLine(x, y, z);

Here are the sort of draw commands I'd expect. I'd bother to hand-write them here, but I've always been pretty down with AS3's graphics API https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/Graphics.html There are a couple of holes in this API from my perspective, but even a subset of this would be fantastic. So I guess the most important are namely:

1. lineStyle

2. beginFill

3. beginGradientFill

4. moveTo

5. lineTo

6. curveTo

7. cubicCurveTo

8. drawCircle

9. drawRect

10. drawRoundedRect

In addition to the list, there are:

• style settings: style.text, style.line.color, style.color, style.font
• drawPolygon (with traingulation)
• radial gradient
• clip
• filter (blur, etc. with css like options?)
• matrix transformation
• drawImage
• drawSVG
• pie (a not closed circle)
• elliptical pie

[lublak]

A few svg ideas:

besides drawLine maybe provide a way to give this line an ID. Instead of a draw method rather a build method which could be built 1:1 the same way but fits better from the name, because a svg graphic is built and not drawn straight. Another method to adjust the built SVG graphic.

context.getSVGElelementById('id').width = 100px;
var ele = context.getSVGElelementById('id');
ele.parent.remove(ele);
var svgElement = context.drawLine(x,y,x2,y2, 'id);

(the svg element would then not have to be completely rebuilt) So two methods: one that is called the first time and one that is called when needsUpdate is true.

instead of drawLine rather createLine()?

different update possibilities? So that you can check yourself how you have to change elements? E.g.

element.width = '100%';

function update(reason) {
    switch(reason) {
        case Resize: 
        case Changed:
        case Moved:
    }
}

if(changed) bakeSvg();

Possibilities of css animations?

[intoxopox]

Guys... I Love the contributions... but, dang if it don't sound like you guys are thinking Just JS target. The whole idea here is to abstract the targets away and offer an agnostic draw API for All HaxeUI targets. Once an agreeable API is established, then work in earnest can begin to deliver such support under the hood for supported backends. That said, implementation ideas are dandy. Let's 1st agree on an API. After that, perhaps Ian can fork the conversation specifically for implementation per backend. A digital elephant is best eaten a byte at a time.

[lublak]

But sometimes it helps to brainstorm the implementation ideas to get a feel for what is possible and how to design the api. What is the point of designing an api if in the end hardly any platform can cope with it. I'm not just thinking about "JS target" but also about how to get all platforms under one hood and therefore also JS/HTML. Btw so extra information for you: These are from a discussion on Discord (between Ian and me) and I wrote them down here so they don't get lost. To design an API you have to know how you want to implement it in something in the end. An API that exists only in the wishful thinking is hardly useful. And as an example on your elephant: You should also know what is tasty and edible in an elephant :P My implementation idea affects the api very strongly.

Some extra: you can render svg on html canvas. I don't know how natural the performance is.

here is a list of characteristics:

• performance
• energy consumption (software surfaces should not be recalculated and drawn every time)
• performance consumption
• operability
• debuggable
• accessibility (select text etc.)
• crisp ui

[ianharrigan]

One thing that is certainly worth considering is performance - intoxopox writes a very involved application that uses A LOT of drawing. It would be interesting (important) to verify what type of difference in performance something like svg vs js canvas you would get.

[intoxopox]

@lublak Touche! I like your implementation notes and meant know disrespect. I mainly just want to keep this thread on task and not in the weeds. That said, to your point, I appreciate how implementation chatter at this stage isn't always necessarily Off point... elephants or otherwise.

[lublak]

@ianharrigan can we close it! :D can we can we? http://haxeui.org/explorer/#basic/canvas and all the best for your wedding! :)

[ianharrigan]

We can! :)