This also adds new functionality to shiny/driver/internal/win32
to be able add custom message handlers to screen window procedure,
and also call new handlers.
Change-Id: I84855db483290de5eed2c82c191be43365dd5f65
Reviewed-on: https://go-review.googlesource.com/19326
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This introduces a free list for Paragraphs, Lines and Boxes.
Also test some Frame / Paragraph / Line / Box invariants.
Change-Id: I764538fda1b2e733e1e62821512ebbb4e5305ebf
Reviewed-on: https://go-review.googlesource.com/19247
Reviewed-by: Andrew Gerrand <adg@golang.org>
The screen.Uploader arg is no longer used, once we got rid of the
screen.UploadedEvent type.
Change-Id: I0fbeb863ec010c3d9b8e79f754a6060361cc719a
Reviewed-on: https://go-review.googlesource.com/19323
Reviewed-by: David Crawshaw <crawshaw@golang.org>
A Buffer is essentially an *image.RGBA, but not all *image.RGBAs are
valid Buffers. This change detects invalid attempts to pass arbitrary
*image.RGBAs as Buffers. Prior to this change, this would 'work' for the
gldriver but not other drivers.
Fixesgolang/go#14191.
Change-Id: I8b0d7f0861dc69b93d332bd0ba26a70326e16c7b
Reviewed-on: https://go-review.googlesource.com/19211
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Upcoming code would like to lean forwards or backwards without requiring
that the Caret is at the end or beginning of a Box.
Change-Id: I2312850b26681df034e9e8fc7835e073fab384eb
Reviewed-on: https://go-review.googlesource.com/19243
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also enforce an int32 max length of a Frame's text buffer.
Change-Id: I7b179395b2e72016d02819e568f088755c04792d
Reviewed-on: https://go-review.googlesource.com/19214
Reviewed-by: Andrew Gerrand <adg@golang.org>
As font.go and plan9font.go say:
// TODO: delete this package. It was deprecated on 2015-09-01.
Change-Id: Ia1ad45238e1718a3071405e4e2310aa5f54d38cb
Reviewed-on: https://go-review.googlesource.com/18795
Reviewed-by: Andrew Gerrand <adg@golang.org>
This makes gldriver behave the same as windriver and x11driver,
making it less likely for an app to 'work' on one driver but not
another.
Updates golang/go#14026.
Change-Id: Id795f6b9f43a67faa954653404a23ae5783f8261
Reviewed-on: https://go-review.googlesource.com/18791
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This differs from e.g. the standard library's clear separation between
io.ReadFull (a function) and io.Reader.Read (a method), but it makes the
calling code a little nicer (see the main.go edits).
Change-Id: I10d03e398e881cf045aa0bd3d8729558768ff871
Reviewed-on: https://go-review.googlesource.com/18659
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This allows Windows to provide state-dependent methods (such as the
window size) that are co-ordinated with the most recent event processed,
as we now track when events are received, not just when they are sent.
Change-Id: I3394bce32923b506c93f151afeb143a8798e4b21
Reviewed-on: https://go-review.googlesource.com/18652
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Set view as the first responder via makeFirstResponder, rather
than setting window.nextResponder to view. This prevents a
segmentation fault when handling mouse events. I am not a cocoa
expert and I don't know why this fixes the problem, but it does
(at least in my tests) and after reviewing the docs it seems
to be what we should have been doing in the first place.
Fixesgolang/go#13895.
Change-Id: Idfba7515dd26b66320c42c8e91a104138ec833eb
Reviewed-on: https://go-review.googlesource.com/18424
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also drop executable bit on some source files.
Change-Id: I08b2db47c8750bb554cfae6b9e78211b2e72718f
Reviewed-on: https://go-review.googlesource.com/18272
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This change does not attempt to handle horizontal scroll events.
Scroll events with a deltaY of > 1 are sent as multiple window events.
Change-Id: Ie77444384cba5e9deec45fba1bfb062b17f115d7
Reviewed-on: https://go-review.googlesource.com/17995
Reviewed-by: David Crawshaw <crawshaw@golang.org>
In (w *windowImpl) Upload, the sr parameter is used to calculate a
sub-image of src when uploading src to a temporary texture, t.
The bounding rectangle of t is then (0,0)-(sr.Dx(),sr.Dy()). The same
sr is then used as the sr parameter to w.Draw when drawing the
temporary texture to the window. However, in the case that sr.Min is
not (0,0), this means that t is incorrectly clipped, and the effect
is that part of the image that was inteded to be uploaded to the
window is missing.
Instead, use t.Bounds() as the sr parameter to w.Draw.
Change-Id: Ib526db0c66856c9ffdd939c943dc9063ffc47c25
Reviewed-on: https://go-review.googlesource.com/18113
Reviewed-by: David Crawshaw <crawshaw@golang.org>
In order to handle the escape and tab keys correctly, key event
handling needs to be moved from an NSResponder implementation
to the NSOpenGLView implementation, and handled with the
performKeyEquivalent method. Without this change, pressing escape
triggers the system beep rather than a keyDown event, and the tab
key yields a keyUp event but no keyDown event.
Change-Id: Ieb28274338249352d08325c0f6eac1d4a4a1c98e
Reviewed-on: https://go-review.googlesource.com/18270
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It appears that the vertex array buffer is very occasionally becoming
unbound as the OpenGL context is passed between threads. This is
causing shiny apps to occasionally start with a blank window.
I have no theory as to why this happens, this was determined
empirically. Rebind the vertex array after drawLoop starts.
While here, ensure that Cocoa has completed running prepareOpenGL
before making any GL calls from another thread. Do this by starting
drawLoop at the end of prepareOpenGL.
Change-Id: Iede19969a7e532e97b67b8ef42b77f05242cc50f
Reviewed-on: https://go-review.googlesource.com/17865
Reviewed-by: Rob Pike <r@golang.org>
- Have Publish block until it is complete.
- Do not block showWindow on makeKeyAndOrderFront, which now blocks
until drawRect is complete. (This deadlocked, as drawRect waited on
code started after showWindow.)
- Always send the window visible lifecycle event when a drawRect
request comes in, as sometimes it hasn't triggered DidExpose yet
which means the initial paint.Event was lost.
- Mark external paint events.
- Avoid using __block where it is not needed to keep the GCD code
easy to reason about.
Change-Id: I2cf652c98835b3ae569d304fa14760271d270d08
Reviewed-on: https://go-review.googlesource.com/17861
Reviewed-by: Rob Pike <r@golang.org>
Removes the need for UploadedEvent. Callers who want concurrent
uploads can use goroutines.
Change-Id: I83dae13fd4ac5059606b1084ed5918857dfeefa8
Reviewed-on: https://go-review.googlesource.com/17272
Reviewed-by: Nigel Tao <nigeltao@golang.org>
A Windows version of the gldriver shares a lot of common code with
the existing windriver. This CL factors it out into a new internal
pacakge, win32.
For golang/go#9306
Change-Id: If602bb42946f1df662b2529d5b277257ae7706d3
Reviewed-on: https://go-review.googlesource.com/17676
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Each window has its own gl.Context.
Change-Id: I33ee97dc8f5d8a8b6e511297880c3b5069736065
Reviewed-on: https://go-review.googlesource.com/16877
Reviewed-by: Andrew Gerrand <adg@golang.org>
With this change, gldriver and x11driver will parse new Width and
Height variables in NewWindowOptions. The change does not implement
parsing of the options in windriver.
Change-Id: I7c23f3b0b580ac9d4cf1d3a31b48fbc2d16046ad
Reviewed-on: https://go-review.googlesource.com/16031
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Add Buffer implementation wrapping image.RGBA, and a dummy
implementation of a Texture. This allows to run shiny/example/basic on
Windows without early failure. This makes it easier to visually verify
implementation of further windriver methods in future.
Also, rename windriver types to screenImpl and windowImpl to match
naming convention used in x11driver.
Change-Id: I30b464e58ac3e973fd98344d221505980de7d5bd
Reviewed-on: https://go-review.googlesource.com/15686
Reviewed-by: Nigel Tao <nigeltao@golang.org>
This fixes example/tile, in that the output is now correct. That app now
flickers, but that will be fixed by either the TODO to recognize simple copies
or scales and the TODO to implement double-buffering.
Change-Id: I53ddd680243255dc116370d18490ff879ed9e5e2
Reviewed-on: https://go-review.googlesource.com/15674
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also fixed the X11 GL driver.
Change-Id: Ie0504d28e35850f98de24477fcf362c4148c82f3
Reviewed-on: https://go-review.googlesource.com/14940
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Still need to change the X11 implementation. (A separate CL?)
Change-Id: Idf4febe691d3bbba2a0dab27f7a92b2d4ce61db3
Reviewed-on: https://go-review.googlesource.com/14910
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Methods like Texture.Upload or Window.Draw are conceptually one
operation but are implemented by multiple OpenGL calls. OpenGL is a
stateful API, so interleaving OpenGL calls from separate higher-level
operations causes inconsistencies.
Change-Id: I66ccf8844d276b82586620c5bfeadb50ba0f5bef
Reviewed-on: https://go-review.googlesource.com/14861
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Previously, bufferImpl's swizzling and clean-up were done outside of
holding the b.mu lock. One goroutine could call b.postUpload and another
call b.Release, and race so that the first goroutine would check
b.released (and see false), release the b.mu lock, and call swizzle.RGBA
(as b.released was false at the time of check). Concurrently, the second
goroutine would now acquire b.mu, set b.released to true, release b.mu,
and then call b.cleanUp. The swizzle and the clean-up don't play well
together.
The fix is hold the mutex for the entirety of the Release, preUpload and
postUpload methods.
Change-Id: Ic40a918cad48a1f2159da7b3410a77faf68cef06
Reviewed-on: https://go-review.googlesource.com/14819
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Previously, bufferImpl's upload method was was:
----
// LINE A.
cookie := shm.PutImage(etc)
// LINE B.
b.s.mu.Lock()
// LINE C.
b.s.uploads[cookie.Sequence] = etc
// LINE D.
b.s.mu.Unlock()
----
The race was that the PutImage call could complete, and be processed by
the X11 event goroutine, after LINE A and before LINE B, so that
screenImpl's handleCompletion would find nothing in the s.uploads map,
and log "no matching upload for a SHM completion event", leaking the
screen.Buffer.
The fix is to increment a counter before LINE A and decrement it after
LINE C, so that the s.uploads map isn't inspected while we're just about
to add something to it.
Change-Id: Ief1cb40129f16dd3fc2ba008c9d1b9be1db05a6d
Reviewed-on: https://go-review.googlesource.com/14818
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Prior to this change, all textures were drawn 1:1 axis-aligned starting
at the top-left corner, regardless of the arguments to Draw.
Change-Id: I3d0cf025eb556f9a3cde56f5cda06415dbb12503
Reviewed-on: https://go-review.googlesource.com/14812
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This change snuck into cl/14743 and breaks drawing on OS X.
Change-Id: I6ead61b68a1a98959e646c29a2a7f61768001b18
Reviewed-on: https://go-review.googlesource.com/14791
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Plenty of new TODOs, and there's probably some refactoring with the
Cocoa gldriver implementation we could do, but I've tried to make the
non-X11-specific changes as small as possible in this CL.
With any refactoring, there's also the (existing) "TODO(crawshaw): there
are several problematic issues around having a draw loop per [Cocoa]
window..." in cocoa.go to think about.
That's all out of scope of this initial CL, which is to land a working
checkpoint.
Change-Id: I11faa749db35b7153385d3a647bc9c6aacd17667
Reviewed-on: https://go-review.googlesource.com/14743
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also remove a redundant fill-with-dark-blue that is immediately
overwritten by the buffer upload.
Also remove an unnecessary size.Event local variable.
Change-Id: I23b5618ce0c93c48d661e08b9d43797cf6c78750
Reviewed-on: https://go-review.googlesource.com/14672
Reviewed-by: Rob Pike <r@golang.org>
Cocoa uses the bottom-left as the origin.
Shiny uses the top-left as the origin.
Convert from one to the other when sending mouse events.
Fixesgolang/go#12306
Change-Id: I462e813e260ec365c978624f9454e7ede0da833d
Reviewed-on: https://go-review.googlesource.com/13917
Reviewed-by: Rob Pike <r@golang.org>
It has been superseded by golang.org/x/image/example/font
Change-Id: Id60514c13a8ffae8bad0f12e14992a719ed7e548
Reviewed-on: https://go-review.googlesource.com/14303
Reviewed-by: David Symonds <dsymonds@golang.org>
The .h file is only included in one place. We might as well inline it.
Change-Id: I69726ffb89c45a8a9b1b3db1e462fa3021121cd5
Reviewed-on: https://go-review.googlesource.com/14230
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Because SendMessage on Windows switches to the thread the
target window is associated with to send the message, we can
safely send messages to windows across threads. As such,
methods on a screen.Window can be implemented by sending
messages to that window directly. This laves the so-called
"utility window" only managing the screen.Screen methods.
Therefore, we rename it to the "Screen window" here, as that
is its function now: providing a thread-safe way to call
screen.Screen methods.
The Go rewrite has the side effect of simplifying the error handling
of Windows API calls a bit.
Some common data-related routines have also been added.
The actual work of creating a window is still done by C.
That will be addressed in the next CL.
Change-Id: Ibe46a57891c34da0e9534d5ab6d19aeb6076e638
Reviewed-on: https://go-review.googlesource.com/13963
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
It now lives at x/image/font, not x/exp/shiny/font.
Change-Id: I65f61ec4ce680f42981016e09c36cd04e140861d
Reviewed-on: https://go-review.googlesource.com/14149
Reviewed-by: David Symonds <dsymonds@golang.org>
The testdata/fixed font files come from the Plan 9 Port, and were all
marked as public domain. The total size of the new testdata is 112K.
Change-Id: I8cf5de4e5abd1aec7e6550d330271f2acdc12402
Reviewed-on: https://go-review.googlesource.com/13888
Reviewed-by: Rob Pike <r@golang.org>
This is consistent with Face.GlyphBounds and Face.GlyphAdvance.
Change-Id: I9da6b4f2fdb8f093fc9567c717e8fbbecc624e30
Reviewed-on: https://go-review.googlesource.com/14090
Reviewed-by: David Symonds <dsymonds@golang.org>
This is an example, still rudimentary, of shiny graphics in action.
This commit has the basic geometry, images, and rendering, but
is missing all the game logic, resizing the board on demand, and
so on, but one can actually play a game using it if one wants.
It has all the built-in computing power of a physical Go board.
Drawings by Renee French. The grid will become a hand drawing
too, soon.
A simple checkpoint.
Change-Id: Id235fa677c59d18cfee0dd96380a0cbca2232c29
Reviewed-on: https://go-review.googlesource.com/14002
Reviewed-by: Nigel Tao <nigeltao@golang.org>
We draw in real time using GetDC. WM_PAINT is only used to
send a paint.Event. To ensure all calls to GetDC only occur on
the main thread, the painting is done using window messages.
Hopefully the code is somewhat self-explanatory. The actual
GDI muckery may appear foreign, but that's GDI for you :/
This will be the last commit that introduces new C code.
Past experience has shown that working with GDI exposes
edge cases in the Go syscall implementation, so I wanted
to get at least Window.Fill working in C so I have a known
good point to work off of. If someone doesn't beat me to it,
I'll start converting the code to pure Go tomorrow.
This introduces the condition that all drawing must be done in
response to a paint.Event. If this is not desired, it can be changed
after the C -> Go conversion.
Change-Id: Ic02669d5f7281fac3c11951ce6a590f9d23dd0a1
Reviewed-on: https://go-review.googlesource.com/13740
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Use the current screen housing the window to calculate scaling
factor and mouse events. Listen for when windows change screen
and update the geometry to match.
Change-Id: I3f05a17be16286e4c8c913cf9662899bf9c2ceaa
Reviewed-on: https://go-review.googlesource.com/13960
Reviewed-by: Rob Pike <r@golang.org>
While I don't expect window size to be expressed in NewWindowOptions
as pixels, right now the window displayed on OS X is 1024x768 scaled
pixels, which doesn't really fit with shiny's use of pixels.
Change-Id: I30608fb3c608e17de40ff72feec1d4b74f53c769
Reviewed-on: https://go-review.googlesource.com/13916
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The WindowResponder was being used after free because the autorelease
pool lifecycle didn't match the window cycle. Release it manually on
window being closed. While here, wire up the close logic.
Removing TODO about managing NSWindow, as the Cocoa docs say that by
default it is released when closed.
Not wiring closing into the paint loop until my other inflight paint
cycle CLs are addressed.
Fixesgolang/go#12268
Change-Id: I5eb692c2dd5b302a608d0535ef191dc01e538c7f
Reviewed-on: https://go-review.googlesource.com/13871
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Two changes. First, create the NSWindow on the main application
thread. I have not found any Cocoa documentation that says this is
necessary, but when in doubt in Cocoa do it on the main thread.
Second, avoid autoreleasing the NSWindow. We are not maintaining any
strong references to it (only the reference from inside the NSView),
so cleaning up the memory is our job. Added a TODO, as when Shiny has
a concept of closing windows, we should free the NSWindow.
Fixesgolang/go#12221
Change-Id: I28098228fd1ab89c263634b1903a34571ea2d595
Reviewed-on: https://go-review.googlesource.com/13741
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Was a TODO, now addressed.
Change-Id: Ib383251d781f126d789050d8f68f4a7e9f73d1ae
Reviewed-on: https://go-review.googlesource.com/13732
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Cocoa support needed some conversions.
Change-Id: I6e01c17cee1fafe9edce1c08391f1eb93491ecd5
Reviewed-on: https://go-review.googlesource.com/13730
Reviewed-by: Nigel Tao <nigeltao@golang.org>
These will be used by other vector font packages, such as the truetype
package, to select specific faces.
Change-Id: I3db8c97335089c2076811e8f85d9a8868fc900bd
Reviewed-on: https://go-review.googlesource.com/13714
Reviewed-by: Rob Pike <r@golang.org>
After this CL, the only source files with build tags are cocoa.* and
other.go:
$ ls
buffer.go
cocoa.go
cocoa.h
cocoa.m
gldriver.go
other.go
screen.go
texture.go
window.go
$ grep --files-with-matches build *
cocoa.go
cocoa.m
other.go
Change-Id: I202c2629e506bb3834d88cc6c8c2e087d8aa0792
Reviewed-on: https://go-review.googlesource.com/13659
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The mouse wheel is not handled yet; I'm not sure how to translate
WM_MOUSEWHEEL to a "click" in the X11 sense yet. I'll find that out
and write that part of the code.
Also I'm not sure if you want Meta to be the Windows key; once I get
confirmation about that I'll add that in too.
For size events, I assume you want to take the device's DPI value as
the PixelsPerPt. I can do that, but Windows has a separate DPI in both
directions; do I only use the one in the Y direction? We'll then need to
handle DPI changes; I can do that too, once I can confirm that
WM_DPICHANGED can be safely included in the switch statement for
window messages on platforms before Windows 8.1.
For paint events, I'll need to figure out how to carry a PAINTSTRUCT
and a DC around. I'll read the examples again and see what I can do.
This will affect the design of Buffer and Texture.
For key events, I just need to know if keys like key.CodeA map to
where the A key is on a US keyboard or on whatever keyboard the
user happens to use (positional or virtual?).
Change-Id: Id8351d197c70715f62a204659349c1692fdec1a3
Reviewed-on: https://go-review.googlesource.com/13670
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Also delete font.MultiFace. We can resurrect a font.MultiFace type if we
need it in the future, but for now, it's simpler if it lives in the
plan9font package.
Change-Id: I1493b47696c323424e7d91cb7fac15505bfdd023
Reviewed-on: https://go-review.googlesource.com/13520
Reviewed-by: Rob Pike <r@golang.org>
This provides the initial implementation of a Windows driver for shiny.
It will only open a window and wait for you to close it; Buffer and
Texture will come next, when I figure out how they will work.
I tried to lay down the design of the package in doc.go. If you are still
confused, I'll be glad to rewrite or expand it.
Currently this uses cgo.
Patch set 2 changes the C formatting to match the Go sourcce tree's.
It also includes a quick change to driver_fallback.go.
Patch set 3 rewrites doc.go, hopefully to be clearer.
Patch set 4 implements changes suggested in code review and
removes a block of comments that was accidentally left in
when doc.go was written.
Patch set 5 formats this commit message.
Change-Id: I2b060455243f445dd0f4c62f6f0c346768491547
Reviewed-on: https://go-review.googlesource.com/13617
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Package font defines an interface for font faces.
Other packages provide font face implementations. For example, a
truetype package (not part of this CL) would provide one based on .ttf
font files.
This CL also introduces the golang.org/x/exp/shiny/font/plan9font
package, a concrete implementation of the font.Face interface for the
Plan 9 bitmap font format.
Change-Id: Iead8914caaa58c7562b18a86b45002ae47486903
Reviewed-on: https://go-review.googlesource.com/13463
Reviewed-by: Rob Pike <r@golang.org>
Adapted from x/mobile/exp/gl/glutil. As shiny.Drawer takes a affine
transform, I've semi-reverted to an earlier version of the glimage
logic that was based on affine transforms. I believe this is correct
(and it can draw the basics on the screen), but it needs more robust
experimentation and testing.
Change-Id: Icc77de0343fe7965b21d6cb4923f521986e088af
Reviewed-on: https://go-review.googlesource.com/13040
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The builders don't have X. (notably Darwin)
Perhaps the Linux ones should. Or some should. Please file a separate bug for that.
Somebody else might want to upstream this fix to BurntSushi.
Updates golang/go#11811
Change-Id: I6d270a83fc59a3923723b5bfbd0b92057a484a1c
Reviewed-on: https://go-review.googlesource.com/12765
Reviewed-by: Nigel Tao <nigeltao@golang.org>
On my amd64 desktop machine:
BenchmarkBGRA-8 3000 469214 ns/op
BenchmarkPureGoBGRA-8 500 3267103 ns/op
When swizzling a 1920x1080 RGBA pixel buffer, there's a 7x difference
between 3.27ms and 0.47ms, and that 3-ish milliseconds difference is a
noticable fraction of the 16.67ms that a 60Hz refresh rate gives you.
Thanks to Aaron Jacobs for his help with SIMD assembly.
Change-Id: I8c1a50cc3f038824e07442492f8f0f6b22c83728
Reviewed-on: https://go-review.googlesource.com/13003
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also have x11driver's Window implement Send, Events and Release.
Change-Id: Ie6c05ca7769937bd6f796e0317cfbc58836f9813
Reviewed-on: https://go-review.googlesource.com/13001
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Beginning of OS X implementation. Can open windows and receive paint
events timed to the physical display's vsync.
Based on x/mobile/app, but with significant modifications to support
opening more than one window.
Implementation of screen.Texture to follow in a later CL.
Change-Id: I84ffad4d636324fa42799cc3bc0079b8b8607162
Reviewed-on: https://go-review.googlesource.com/12927
Reviewed-by: Nigel Tao <nigeltao@golang.org>
As the README.vendor file says:
----
This is a fork-and-subset of github.com/BurntSushi/xgb at git revision
3ac861bb (2015-04-26).
The subset consists of these directories:
github.com/BurntSushi/xgb
github.com/BurntSushi/xgb/render
github.com/BurntSushi/xgb/shm
github.com/BurntSushi/xgb/xproto
Other directories in the original github.com/BurntSushi/xgb repository
are not used by golang.org/x/exp/shiny, and were not copied to the
vendor tree here:
github.com/BurntSushi/xgb/bigreq
github.com/BurntSushi/xgb/composite
etc
github.com/BurntSushi/xgb/xvmc
----
Change-Id: I7702bd31443239269b7218c368e27802fbfed78a
Reviewed-on: https://go-review.googlesource.com/12814
Reviewed-by: Andrew Gerrand <adg@golang.org>
This introduces a new dependency on third-party libraries:
github.com/BurntSushi/xgb/...
Change-Id: Ibe6e8422b356b9225ef0a44d0f42b34fd2cda61d
Reviewed-on: https://go-review.googlesource.com/12668
Reviewed-by: Rob Pike <r@golang.org>