mirror of
https://gitlab.gnome.org/GNOME/gtk.git
synced 2024-11-09 10:20:07 +00:00
896ea5b753
linear will average all the pixels for the lod, nearest will just pick one (using the same method as OpenGL/Vulkan, picking bottom right center). This doesn't really make linear/nearest filtering work as it should (because it's still a form of mipmaps), but it has 2 advantages: 1. it gets closer to the desired effect 2. it is a lot faster Because only 1 pixel is chosen from the original image, instead of averaging all pixels, a lot less memory needs to be accessed, and because memory access is the bottleneck for large images, the speedup is almost linear with the number of pixels not accessed. And that means that even for lot level 3, aka 1/8th scale, only 1/64 of the pixels need to be accessed, and everything is 50x faster. Switching gtk4-demo --run=image_scaling to linear/nearest makes all the lag go away for me, even with a 64k x 64k image.
34 lines
2.2 KiB
C
34 lines
2.2 KiB
C
#pragma once
|
|
|
|
#include "gskgpuopprivate.h"
|
|
|
|
#include "gsktypes.h"
|
|
|
|
G_BEGIN_DECLS
|
|
|
|
typedef void (* GskGpuCairoFunc) (gpointer user_data,
|
|
cairo_t *cr);
|
|
|
|
GskGpuImage * gsk_gpu_upload_texture_op_try (GskGpuFrame *frame,
|
|
gboolean with_mipmap,
|
|
guint lod_level,
|
|
GskScalingFilter lod_filter,
|
|
GdkTexture *texture);
|
|
|
|
GskGpuImage * gsk_gpu_upload_cairo_op (GskGpuFrame *frame,
|
|
const graphene_vec2_t *scale,
|
|
const graphene_rect_t *viewport,
|
|
GskGpuCairoFunc func,
|
|
gpointer user_data,
|
|
GDestroyNotify user_destroy);
|
|
|
|
void gsk_gpu_upload_glyph_op (GskGpuFrame *frame,
|
|
GskGpuImage *image,
|
|
PangoFont *font,
|
|
PangoGlyph glyph,
|
|
const cairo_rectangle_int_t *area,
|
|
const graphene_point_t *origin);
|
|
|
|
G_END_DECLS
|
|
|