x/mobile driver about gxui HOT 7 CLOSED

I'm up for it :)
Let me know if there's anything I can do to help.

from gxui.

I would prefer gotk3/gtkmm over gxgui. Layout and treeview are mature in gtkmm and map well over X-Window. Gotk3 also helps to reduce the time relearning another api that already works on win64, Linux and osx.

from gxui.

I was just going to open an issue about this and more... Now I'm not sure if I should post here or new issue.

from gxui.

+1

from gxui.

I'm working on this now (alongside with adding WebGL backend to x/mobile/gl, as discussed in #49).

from gxui.

Okay, I've got a working version of the driver that uses x/mobile/gl and runs both on desktop, and in browser (via the new WebGL backend).

I ran into two more x/mobile/gl API issues while making this. One is described at golang/go#10218 (comment).

The other has to do with with x/mobile/gl.BufferData:

func BufferData(target Enum, src []byte, usage Enum)

gxui currently tries to support multiple src types like []float32, []uint8, []uint16, []uint32. I'm only aware of f32.Bytes helper to convert []float32 data to []byte at this time.

For now, I did a quick hack to get it to run:

func CreateIndexBuffer(ty PrimitiveType, data16 []uint16) *IndexBuffer {
    // HACK: I know only `USHORT` PrimitiveType is being used atm,
    //       so this was the quickest thing to get it to compile and run. Assumes LittleEndian.
    data := make([]byte, len(data16)*2)
    for i, v := range data16 {
        data[2*i+0] = byte(v >> 0)
        data[2*i+1] = byte(v >> 8)
    }

    ...

But we need to think of the right long term solution. There's more than one option, each with tradeoffs (performance vs. generality of code and ability to run on platforms with different endianness, etc.).

from gxui.

I just need to clean up a little and rebase on top of latest master, then I can make a PR for review and potential merging.

But before I can do that, I need to know the following:

• Would you prefer a PR that changes/replaces the current drivers/gl from using github.com/go-gl/gl/v2.1/gl to one that uses golang.org/x/mobile/gl (with only desktop and mobile support, WebGL to be added, and no Windows support yet)? Or would you prefer a PR that adds a 2nd driver that is a copy of the current gl driver with the only difference that it uses golang.org/x/mobile/gl?

The advantage of replacing current driver is that it will receive most thorough testing as everyone will be using it (and the samples don't need to be duplicated, one for each driver).

The disadvantage is that I expect golang.org/x/mobile/gl to be slightly slower since it's a higher level OpenGL/OpenGL ES/WebGL interface than github.com/go-gl/gl/v2.1/gl. Additionally, golang.org/x/mobile/gl currently does not support Windows (see issue golang/go#9306). And it also needs a few more API fixes (see golang/go#10218 (comment)).

I am guessing it's better to go for 2 separate drivers for now, so that will be my upcoming PR. But feel free to comment on that.

from gxui.