Similar to existing supprresions for bogus errors in GrConvertPixels.
Change-Id: I50f3b47ca3a88c71af532fa69aa2566ad0f03753
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/252802
Commit-Queue: Brian Salomon <bsalomon@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Auto-Submit: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Give it its own header file.
Make it store SkISize rather than separate int w/h.
Change-Id: I732f2774c561decac743a950959a70cbc162b67b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/245163
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This reverts commit 27239e456a.
Revert "Revert "Add function to GrDataUtils to handle color conversions.""
This reverts commit c34d993b62.
Change-Id: Iac1bdaa6f8380e63bbb87394e7fca96808572131
Bug: skia:8962
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222039
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Bug: skia:
Change-Id: I813fe71812ec65778b48b8b13f238b8df7b8f8cd
Reviewed-on: https://skia-review.googlesource.com/21360
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Valgrind has tipped over from seeing the keep-alive thread as possibly
leaked to seeing it as definitely leaked. We can suppress both.
An alternative here is "all" or to just remove the line. For the moment
I think this is best, as we're still excluding indirect leaks this way.
I'd want to think a bit whether it made sense for the keep-alive thread
to indirectly leak anything, so I'd like it to fail if it comes up.
Change-Id: Ib28790a1d84a0a9061fdb6de48569ca8ea51b52a
Reviewed-on: https://skia-review.googlesource.com/8764
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
It appears that the top-level function named has switched to just "main"
Change-Id: I33a18a8d433867e759312d09e5b258f934f495a4
Reviewed-on: https://skia-review.googlesource.com/8194
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
This is a follow up to building the Valgrind bots with GN.
It's not clear why these need to leak, but we might as well
update the suppressions. The stacks now look like this:
Memcheck:Leak
match-leak-kinds: possible
fun:calloc
fun:_dl_allocate_tls
fun:pthread_create@@GLIBC_2.2.5
fun:_ZN8SkThreadC1EPFvPvES0_
fun:_Z14nanobench_mainv
fun:(below main)
We suppress fun:main in that last slot, so just make it ...
TBR=
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2347153002
Review-Url: https://codereview.chromium.org/2347153002
The fixes are in the updated libjpeg-turbo repository
pulled in by DEPS. The fixes are detailed in the linked
skia bug. To summarize briefly, we now use calloc()
instead of malloc().
BUG=skia:4030
Review URL: https://codereview.chromium.org/1237213004
FontConfig uses offsets for elements instead of pointers, so any value
held by an element goes missing from memory checkers. Previous
suppressions took care of rule copies and adds to elements, but value
lists may be copied as well. When they are, values are copied, including
the content of strings and matricies. Since value lists are effectively
like Fc*Add functions (even calling the same underlying helpers), treat
them as such and suppress any 'leaks' they may cause.
Review URL: https://codereview.chromium.org/894863003
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.orgTBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
SkTaskGroup is like SkThreadPool except the threads stay in
one global pool. Each SkTaskGroup itself is tiny (4 bytes)
and its wait() method applies only to tasks add()ed to that
instance, not the whole thread pool.
This means we don't need to bring up new thread pools when
tests themselves want to use multithreading (e.g. pathops,
quilt). We just create a new SkTaskGroup and wait for that
to complete. This should be more efficient, and allow us
to expand where we use threads to really latency sensitive
places. E.g. we can probably now use these in nanobench
for CPU .skp rendering.
Now that all threads are sharing the same pool, I think we
can remove most of the custom mechanism pathops tests use
to control threading. They'll just ride on the global pool
with all other tests now.
This (temporarily?) removes the GPU multithreading feature
from DM, which we don't use.
On my desktop, DM runs a little faster (57s -> 55s) in
Debug, and a lot faster in Release (36s -> 24s). The bots
show speedups of similar proportions, cutting more than a
minute off the N4/Release and Win7/Debug runtimes.
BUG=skia:
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/531653002
