Last active 14 minutes ago

#292 Older intel CPU vulkan corruption 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I've filed an upstream issue.

#291 Android apps don't respond to input from pen/stylus 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Fixed by https://gioui.org/commit/4d22a926. Thanks, ~dstaley.


#293 Removal of gtx.Version() prevent detect same frame 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

It sounds to me you're abusing your clickables to serve as event buses to several listeners. I'm not sure that's a good idea to overload widgets like that, just because they happen to be available everywhere. Maybe something like @whereswaldon's skel is a better fit?

It also sounds like you found a workaround, so I'm closing this issue. If you come up with a concrete proposal for supporting your use-case and why it should be solved at the widget level, please re-open or file another issue.


#293 Removal of gtx.Version() prevent detect same frame 4 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Fri Oct 15, 2021 at 11:52 CEST, ~inkeliz wrote:

I'm using a old version of Gio, but I notice that https://github.com/gioui/gio/commit/87d050bcc7145227f08cac864f7e668526e835a4 removes the gtx.Version().

I have some widgets that uses such function to detect when the function is called in the same frame.

For instance:

type Button struct {
     clicked int

func (e *Button) Clicked(gtx layout.Context) bool {
       if e.clicked == gtx.Version() {
            return true
       e.clicked = 0

	for _, ev := range gtx.Events(&e.handler) {
        // ...
	if clicked {
		key.SoftKeyboardOp{Show: false}.Add(gtx.Ops)
               	e.clicked = gtx.Version()
	return clicked

The gtx.Version() was necessary to allow multiple if button.Clicked(gtx){} in the same frame. In that case, the first call will set the e.clicked to the current frame version, any other call will check it first.

There's no other alternative.

Removing op.Ops.Version wasn't a mistake: it's internal. However, I'd still like to understand your use-case so we might restore similar functionality.

Reset the e.clicked to false on Layout() can lead to some problems, if the button doesn't appear in the next frame.

That solution seemed natural. What problems occur when a button doesn't appear in a frame? It may be useful that pointer.Cancel is sent to pointer.InputOps that hasn't appeared for a frame.

#291 Android apps don't respond to input from pen/stylus 4 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Thu Oct 14, 2021 at 21:07 CEST, ~dstaley wrote:

I'm fairly sure [this switch](https://git.sr.ht/~eliasnaur/gio/tree/main /item/app/os_android.go#L648) needs to handle a C.AMOTION_EVENT_TOOL_TYPE_STYLUS case ([Android docs](https://develope r.android.com/reference/android/view/MotionEvent#TOOL_TYPE_STYLUS)). I'd be happy to test and send a patch, but I'm a bit unsure of how to get things up and running. I have both Go and Android experience, but not the two combined!

If you have the time and the SDK+NDK installed, I believe you can setup a development environment with something like

$ git clone https://git.sr.ht/~eliasnaur/gio-example $ git clone https://git.sr.ht/~eliasnaur/gio $ cd gio-example $ go mod edit -replace gioui.org=../gio $ ANDROID_SDK_ROOT=<path/to/android/sdk> go run gioui.org/cmd/gogio@latest -target ./kitchen

If everything goes well, you'll have a kitchen.apk ready to install to your device:

$ adb install kitchen.apk

You should then be able to re-run the gogio command after editing os_android.go (or other files).


#292 Older intel CPU vulkan corruption 4 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Setting GIORENDERER=forcecompute should enable the compute renderer.

#292 Older intel CPU vulkan corruption 4 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Are there warnings on the console about missing conformance like there is for Ivy Bridge? Does the compute renderer work?

I assume this is a driver problem, given the GL fallback works. If so, it would be nice to reduce this to something reportable to upstream, but for now we'd probably just need a driver check and fall back to GL.

#291 Android apps don't respond to input from pen/stylus 5 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I don't think permissions matter. Android most likely reports events regardless.

#290 `rr record` execution fails with `eglInitialize failed` 7 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I'm inclined to close this as NOT_OUT_BUG until proven otherwise. Does rr work with other GL and Vulkan programs on your system?

#287 don't use vulkan on intel gpus with incomplete support for it 9 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Thanks for confirming. I'm going to close this issue.

I'm ok with a patch implementing a conformance check, but I'm skeptical whether there are real world examples of it helping:

  • VkConformanceVersion requires Vulkan 1.2 (or VK_KHR_driver_properties). It seems to me very few vendors (Intel only?) will bother to implement Vulkan 1.2 without also covering all Gio's OpenGL ES 2.0-level use of Vulkan.
  • The check won't catch Intel GPU bugs before your patch has landed in most distributions. That's at least a year from now.
  • Will the conformance check rule out a future MoltenVK or similar implementation?

I could also imagine Linux distributions phasing out OpenGL drivers in favour of OpenGL-on-Vulkan drivers in future. Which means our GL fallback will become less useful.