Since we are now referencing the exact methods instead of calling
GetProcAddress, there is no need to cast the function pointers. This
also catches a bug where the emscripten signatures for glWaitSync and
glClientWaitSync did not match the OpenGL API.
Change-Id: If365a8f6090961cb4b44146d87e102430bc5b30f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/320659
Commit-Queue: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This saves about 15kb of wasm code size (4kb gzipped), 11kb
of JS code size (2kb gzipped) and about 10ms
when creating a new surface (~35ms -> 25ms in a local test).
This also gates the webgl code more strongly (off unless you
really request it), since the headers won't be available
except in an emscripten environment.
Change-Id: I303f6c342c72e7cfe29be241f55ae8f5631a3f75
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/311916
Reviewed-by: Brian Salomon <bsalomon@google.com>
Surfaces to client whether GrContext has seen a GL_OUT_MEMORY,
VK_ERROR_OUT_OF_HOST_MEMORY, or VK_ERROR_OUT_OF_DEVICE_MEMORY error.
Bug: chromium:1093997
Change-Id: I8e9799a0f7d8a74df056629d7d1d07c0d0a0fe30
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/298216
Reviewed-by: Greg Daniel <egdaniel@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This CL has a complicated back story, but it's concrete change is
simple, just turning the warning on and converting a bunch of
return foo;
to
return std::move(foo);
These changes are exclusively in places where RVO and NRVO do not apply,
so it should not conflict with warnings like -Wpessimizing-move.
Since C++11, when you return a named local and its type doesn't match
the declared return type exactly, there's an implicit std::move()
wrapped around the value (what I'm making explicit here) so the move
constructor gets an opportunity to take precedence over the copy
constructor. You can read about this implicit move here under the
section "automatic move from local variables and parameters":
https://en.cppreference.com/w/cpp/language/return#Notes.
This situation comes up for us with smart pointers: a function declares
its return type as std::unique_ptr<Base> or sk_sp<Base>, and we return a
std::unique_ptr<Impl> or sk_sp<Impl>. Those types don't match exactly,
so RVO and NRVO don't come into play. They've always been going through
move constructors, and that's not changed here, just made explicit.
There was apparently once a bug in the C++11 standard and compilers
implementing that which made these copy instead of move, and then this
sort of code would do a little unnecessary ref/unref dance for sk_sp,
and would entirely fail to compile for uncopyable std::unique_ptr.
These explicit moves ostensibly will make our code more compatible with
those older compilers.
That compatibility alone is, I think, a terrible reason to land this CL.
Like, actively bad. But... to balance that out, I think the explicit
std::move()s here actually help remind us that RVO/NRVO are not in play,
and remind us we're going to call the move constructor. So that C++11
standard bug becomes kind of useful for us, in that Clang added this
warning to catch it, and its fix improves readability.
So really read this all as, "warn about implicit std::move() on return".
In the end I think it's just about readability. I don't really hold any
hope out that we'll become compatible with those older compilers.
Bug: skia:9909
Change-Id: Id596e9261188b6f10e759906af6c95fe303f6ffe
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/271601
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I127c979670c3dc7dac2e35908a795afbdefca8f6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234902
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Tested by:
cd tools/gpu/gl/interface/
go run *.go --in_table "./interface.json5" -out_dir "../../../../src/gpu/gl/"
Cq-Include-Trybots: skia.primary:Housekeeper-PerCommit-CheckGeneratedFiles
Change-Id: I1fee1263e321580c0e8c4e41d345fc856ef2a4e7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/210128
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
There is some logic in here for 2.0 as well, just as a
"as long as I was looking at the specs", but only 1.0
is really supported.
This seems to resolve the bug where some GPUs weren't
advertising correctly that they had vertex array object
support, by checking for both extension names (with and
without "GL_" prefix)
Of note, this saves about 18 Kb (5.5 Kb gzipped) of code size
by compiling out the unneeded GLES checks/functionality.
Bug: skia:8378
Change-Id: I773bf4dbf231b991051d2a9f640b8047a9010e7d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/203461
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
This reverts commit 93b3dce89d.
Revert "Delete old assembleInterface code"
This reverts commit 7b1cf20d47.
Revert "Delete in favor of autogenerated file"
This reverts commit 0223bd01d8.
Bug: skia:8474
NOTRY:true
Change-Id: I23a904347f9d6cefd1710a2de056c39d52f4b178
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/203463
Reviewed-by: Stan Iliev <stani@google.com>
Commit-Queue: Stan Iliev <stani@google.com>
This CL creates a go program that takes a JSON file of
GPU functions and creates the assemble and validate code
based on that.
This approach will hopefully will lessen the need for
"shotgun surgery" anytime a new function/extensions is added.
Additionally, it should be easier to add a new standard
(concretely, WebGL) using this technique.
There are a few potential bugs/mismatches in the current
implementation that this has identified, for example,
Requiring GL 3.x for adding a feature, but only verifying
it is there on GL 4.x - I did not attempt to correct these
bugs in the old version, as we will hopefully be able to delete
that version and use the generated files.
Bug: skia:8474, skia:8378
Change-Id: Ie8144bbab8e03f2c815fd942fa9f7f91dedba101
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202137
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
