Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

graphics: HTML5-Canvas-like API #137

Closed
hajimehoshi opened this issue Feb 5, 2016 · 33 comments

Comments

@hajimehoshi
Copy link
Owner

commented Feb 5, 2016

Random note

How to implement

For simple primitives, GLSL would work. For complex things like filling polygon, GLSL would also work but stencil buffers might be better.

Or, how about implementing scan-line algorithm on GLSL without vertices?

What kind of features there are in HTML5 Canvas

Ref: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D

  • Shapes / Paths

    • Line
    • Rectangle
    • Polygon
    • Arc
      • Circle
      • Ellipse
    • Bezier Curve
    • Quadratic Curve
  • Line style

    • Width
    • Cap
    • Join
    • Miter Limit
    • Dash
  • Fill/Stroke Style

    • Solid
    • Gradient
    • Pattern
  • Shadow

    • Blur
    • Color
    • Offset
  • Paths

    • Fill (non-zero / even-odd) (NanoVG supports only even-odd)
    • Stroke
    • Clip
  • Others

    • imageSmoothingEnabled (Anti alias)

I don't think we need all the above items though...

Text

As for text rendering, we already have github.com/hajimehoshi/ebiten/text and that's fine. For true type fonts, using bezier curves might be more effective, but the text package accepts more general font.Face interface, that can be any rasterized data.

Filling pattern / Clip

We already have composition modes, so I don't think we need API to specify complex filling pattern and clipping. Just filling with a solid color might be enough.

Actual use cases

I need actual use cases before considering API. This is similar way to Go2 language change.

  • Prototyping
  • Graphs or charts
  • UI

@hajimehoshi hajimehoshi added this to the v1.3.0 milestone Feb 5, 2016

@hajimehoshi hajimehoshi added the feature label Feb 6, 2016

@hajimehoshi hajimehoshi changed the title HTML5-Canvas-like API graphics: HTML5-Canvas-like API Feb 17, 2016

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Feb 17, 2016

Let's see what NanoVG https://github.com/memononen/nanovg is doing and decide if I should convert this into Go or take another way.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Jul 25, 2017

(This comment has been moved to the top comment)

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Jul 26, 2017

It looks like pygame has not-so-complex API

http://www.pygame.org/docs/ref/draw.html

@joeblew99

This comment has been minimized.

Copy link

commented Aug 7, 2017

@hajimehoshi my use case is to design high quality UI.

The first comment you make in this issue pretty much sums it up. It also makes sense to use Canvas2D Web as a basis.

I guess its a matter of implementing these for opengl also ? These i assume woudl be GLSL accelerated ?

--

i am fiddling around with how to make it easier to design with these primitives. Almost like a higher level markup. I knwo that is out of scope, but just letting you know.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Aug 7, 2017

my use case is to design high quality UI.

Speaking of high quality, you might need #395. Ebiten now treats only platform-independent pixels and can't draw high resolution images that matches high-dpi displays.

I understand your use case but introducing such big feature is very risky and I'd like to consider it very carefully.

The first comment you make in this issue pretty much sums it up. It also makes sense to use Canvas2D Web as a basis.
I guess its a matter of implementing these for opengl also ? These i assume woudl be GLSL accelerated ?

I'm thinking to use GLSL. Canvas2D is useful but it would make Ebiten internal implementation more complex.

@joeblew99

This comment has been minimized.

Copy link

commented Aug 8, 2017

I noticed the DPI problem too so glad you mentioned it.

Regarding using glsl, I think your right.
If you have a basic example of doing it with glsl I can try out different use cases to extent it and see how I go and push it's back if I get anything worthwhile going.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Aug 8, 2017

No examples here.

BTW, if you want to make a UI, doesn't 9-patches way work?

@joeblew99

This comment has been minimized.

Copy link

commented Aug 12, 2017

yeah i saw the 9 patches technique you used.
Its basically just a raster image though ?
My main reason for bringing this up is to support different screen sizes. That tends to mean

  • making the source of controls vector based. I was thinking about an idea of creating raster images at compile time and embedding them as a work around.
  • detecting DPI at runtime.
  • layout constraints to allow the different GUI components to resize based on screen size differences and window resizes.
@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Aug 12, 2017

OK, so how about detecting the platform's DPI and using 9-patches? You'd need to prepare same images for multiple resolutions.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Aug 13, 2017

http://godoc.org/github.com/hajimehoshi/ebiten/ebitenutil#DrawLine Added DrawLine and DrawRect mainly for debugging or prototyping purpose. These are just for debugging, and we might still need HTML5-Canvas-like APIs.

@joeblew99

This comment has been minimized.

Copy link

commented Aug 20, 2017

Regarding detecting the DPI can we do that now ?

Regarding the drawing primitives (line and rect). GREAT ! just what we need to get going.
Next will be to try out constraint solvers for different layouts and resizes. There are good ones in match that can be used. Am playing around with option.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Aug 20, 2017

Regarding detecting the DPI can we do that now ?

I wanted to know whether you really need vector graphics instead of 9-patches. If we can know DPI, I think 9-patches would work even in high-definition.

@joeblew99

This comment has been minimized.

Copy link

commented Aug 21, 2017

Maybe it's best if I just explain what I am doing with ebiten and where I am hitting problems.

On desktop I need to run full screen.
At the moment this results in the ebiten canvas getting scaled up to fit the entire window / full screen.

So I guess knowing the DPI will allow us to start to render elements at the right size.

Most of my GUI uses the lines and reactances primitives in ebiten. I also do use images for logos and things like that

So I am guessing then that once we know the DPI we can start to do some logic in the way we scale things...

Sorry about late reply !

@joeblew99

This comment has been minimized.

Copy link

commented Aug 21, 2017

I am currently using the constraints engine in matcha to layout UI and have it adapt to new content and screen sizes in terms of responsive design.

Thought this is relevant since you asked for use cases.

His code does the layout calc at golang level and then sends all sizes to native GUI over protocol buffers, which is if course a different architecture stack to ebiten. But the point is that the layout / constraints code works fantastically and could be used to help with the scaling aspects that all developers will inevitably hit with different screen sizes and DPI.

https://github.com/gomatcha/matcha/tree/master/layout

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Aug 22, 2017

OK so probably what you want is to detect the native DPI. Let's discuss at #395 if needed.

@joeblew99

This comment has been minimized.

Copy link

commented Aug 23, 2017

Ok i asked over at #395

@seebs

This comment has been minimized.

Copy link
Contributor

commented Dec 30, 2017

As a person who wants and uses primitives: Pixel's interface to these is moderately useful. Of particular note/import are polylines. Polyline support is very helpful for a lot of use cases. But even just line segments that can specify world-space width and length and transforms are pretty handy. And honestly, a "rect" type that can do arbitrary transforms is probably fine, but there are definite performance advantages to being able to specify more stuff in fewer vertexes. (Polyline approaches one point per line segment; rectangles are two triangles per line segment, and require you to compute four or six points, depending.)

For my immediate purposes, I'll probably just make a generic texture that's all-pixels-FFFFFFFF, and draw scaled/rotated copies.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Dec 30, 2017

For my immediate purposes, I'll probably just make a generic texture that's all-pixels-FFFFFFFF, and draw scaled/rotated copies.

ebitenutil.DrawRect and DrawLine do the same thing. Please take a look: https://godoc.org/github.com/hajimehoshi/ebiten/ebitenutil#DrawLine

@seebs

This comment has been minimized.

Copy link
Contributor

commented Dec 30, 2017

They do, but DrawLine doesn't seem to have a width specification, and DrawRect doesn't provide a rotatable thing. So if I want a pretty antialiased line-segment-like-thing, I think I need to draw an "image", even if it's an all-pixels-white image, so I have all the transforms available.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Dec 30, 2017

Ah, that makes sense.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Dec 30, 2017

@seebs

This comment has been minimized.

Copy link
Contributor

commented Dec 30, 2017

As many as I can. 20k sounds good. Fewer is probably fine. depends on other issues also.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Jan 9, 2018

Current idea:

  • Add a new API to Ebiten to draw just polygons with solid color (or another way? I don't know)
  • Add a new package to offer new APIs to draw shapes implemented by the new API and poly2tri algorithm (and FXAA algorithm)

The good thing is that only one API is required in Ebiten. This is very generic and minimalistic.

@hajimehoshi hajimehoshi added this to the v2.0.0 milestone Jan 9, 2018

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Jan 27, 2018

https://github.com/hajimehoshi/go-libtess2 Ported a tessellation lib to Go. Theoretically, any shapes can be drawn if Ebiten has an API to draw given vertices.

@hajimehoshi hajimehoshi removed this from the v2.0.0 milestone Apr 16, 2018

@Splizard

This comment has been minimized.

Copy link

commented Apr 28, 2018

What's the status of drawing shapes in ebiten? Rectangles are trivial, is there an efficient way to draw triangles / circles ?

The standard use case for me would be debugging collisions, having an easy way to draw circles and triangles is a quick way to visualize collision boxes.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Apr 28, 2018

No progress so far. Now I'm busy with working on performance optimization especially for mobiles.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Apr 28, 2018

The standard use case for me would be debugging collisions, having an easy way to draw circles and triangles is a quick way to visualize collision boxes.

Ah, that makes sense...

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Aug 13, 2018

This can be indirectly supported by DrawTriangle. I think adding a package to draw primitive shapes would be very useful.

@hajimehoshi hajimehoshi added this to the v2.1.0 milestone Aug 13, 2018

@lei-cao

This comment has been minimized.

Copy link

commented Aug 24, 2018

What about directly using other libraries like
https://github.com/fogleman/gg and
https://github.com/llgcode/draw2d/

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Sep 22, 2018

They manipulates pixels and doesn't use polygons, right?

@hajimehoshi hajimehoshi modified the milestones: v2.1.0, v1.9.0 Sep 22, 2018

@hajimehoshi hajimehoshi modified the milestones: v1.9.0, v1.10.0 Dec 21, 2018

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Apr 12, 2019

As the first step, I think I'll implement these features:

  • Shapes:
    • Line
    • Rectangle
    • Circle
    • Ellipse
    • Arc
  • Option to fill or not

Reference: https://www.pygame.org/docs/ref/draw.html

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Apr 13, 2019

https://godoc.org/github.com/hajimehoshi/ebiten/vector Created a 'vector' package. I think I'll add more various functions to Path.

@hajimehoshi

This comment has been minimized.

Copy link
Owner Author

commented Apr 14, 2019

Let me close this issue by the following issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.