RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/video/out/gpu/osd.c

364 lines
11 KiB
C
Raw Normal View History

vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
/*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* This file is part of mpv.
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
*
Change GPL/LGPL dual-licensed files to LGPL Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
2016-01-19 17:36:34 +00:00
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* mpv is distributed in the hope that it will be useful,
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Change GPL/LGPL dual-licensed files to LGPL Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
2016-01-19 17:36:34 +00:00
* GNU Lesser General Public License for more details.
gl_osd: fix license header All vo_gl.c related code has been GPL+LGPL dual-licensed. The OSD code is no exception and is also derived from vo_gl.c. Thus it should have the same license (although I think technically speaking sub-licensing it by removing one of the licenses is ok).
2015-06-08 20:13:00 +00:00
*
Change GPL/LGPL dual-licensed files to LGPL Do this to make the license situation less confusing. This change should be of no consequence, since LGPL is compatible with GPL anyway, and making it LGPL-only does not restrict the use with GPL code. Additionally, the wording implies that this is allowed, and that we can just remove the GPL part.
2016-01-19 17:36:34 +00:00
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
*/
#include <stdlib.h>
#include <assert.h>
sub, vo_opengl: use packed sub-bitmaps directly if available The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
2016-06-17 21:11:05 +00:00
#include <limits.h>
vo_opengl: remove another unneeded GL include Getting mp_pass_perf seriously requires including vo.h???
2017-08-11 18:11:21 +00:00
#include "common/common.h"
#include "common/msg.h"
#include "video/csputils.h"
#include "video/mp_image.h"
vo_opengl: remove gl_ prefixes from files in video/out/opengl This is a bit redundant with the name of the directory itself, and not in line with existing naming conventions.
2015-08-29 02:12:56 +00:00
#include "osd.h"
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
vo_opengl: osd: use new VAO mechanism In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
2017-07-22 19:53:50 +00:00
#define GLSL(x) gl_sc_add(sc, #x "\n");
vo_opengl: fix alpha values written to the framebuffer When blending OSD and subtitles onto the video, we write bogus alpha values. This doesn't normally matter, because these values are normally unused and discarded. But at least on Wayland, the alpha values are used by the compositor and leads to transparent windows even with opaque video on places where the OSD happens to use transparency. (Also see github issue #338.) Until now, the alpha basically contained garbage. The source factor GL_SRC_ALPHA meant that alpha was multiplied with itself. Use GL_ONE instead (which is why we have to use glBlendFuncSeparate()). This should give correct results, even with video that has alpha. (Or at least it's something close to correct, I haven't thought too hard how the compositor will blend it, and in fact I couldn't manage to test it.) If glBlendFuncSeparate() is not available, fall back to glBlendFunc(), which does the same as the code did before this commit. Technically, we support GL 1.1, but glBlendFuncSeparate is 1.4, and I guess we should try not to crash if vo_opengl_old runs on a system with GL 1.1 drivers only.
2013-11-10 02:14:13 +00:00
// glBlendFuncSeparate() arguments
static const int blend_factors[SUBBITMAP_COUNT][4] = {
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
[SUBBITMAP_LIBASS] = {RA_BLEND_SRC_ALPHA, RA_BLEND_ONE_MINUS_SRC_ALPHA,
RA_BLEND_ONE, RA_BLEND_ONE_MINUS_SRC_ALPHA},
sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRA This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
2022-01-11 20:03:27 +00:00
[SUBBITMAP_BGRA] = {RA_BLEND_ONE, RA_BLEND_ONE_MINUS_SRC_ALPHA,
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
RA_BLEND_ONE, RA_BLEND_ONE_MINUS_SRC_ALPHA},
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
};
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
struct vertex {
float position[2];
float texcoord[2];
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
uint8_t ass_color[4];
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
};
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
static const struct ra_renderpass_input vertex_vao[] = {
{"position", RA_VARTYPE_FLOAT, 2, 1, offsetof(struct vertex, position)},
{"texcoord" , RA_VARTYPE_FLOAT, 2, 1, offsetof(struct vertex, texcoord)},
{"ass_color", RA_VARTYPE_BYTE_UNORM, 4, 1, offsetof(struct vertex, ass_color)},
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
};
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct mpgl_osd_part {
enum sub_bitmap_format format;
osd: simplify an aspect of change detection handling There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
2015-03-18 11:33:14 +00:00
int change_id;
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
struct ra_tex *texture;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
int w, h;
int num_subparts;
vo_rpi: redraw subtitles only on change Since vo_rpi uses MMAL for video output, which is completely independent from the GLES overlay, we can just not redraw the GLES screen if subtitles do not change. (As a furhter optimization, the dispmanx overlay could be removed if nothing is visible. But I'm not sure if adding and removing the overlay frequently is a good idea for performance, so this could just as well go the other way.)
2015-08-18 20:59:22 +00:00
int prev_num_subparts;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct sub_bitmap *subparts;
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
int num_vertices;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct vertex *vertices;
};
struct mpgl_osd {
struct mp_log *log;
struct osd_state *osd;
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
struct ra *ra;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct mpgl_osd_part *parts[MAX_OSD_PARTS];
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
const struct ra_format *fmt_table[SUBBITMAP_COUNT];
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
bool formats[SUBBITMAP_COUNT];
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
bool change_flag; // for reporting to API user only
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
// temporary
int stereo_mode;
vo_opengl, osd: allow osc.lua to react faster on resizes Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
2016-03-21 21:23:41 +00:00
struct mp_osd_res osd_res;
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
void *scratch;
};
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
struct mpgl_osd *mpgl_osd_init(struct ra *ra, struct mp_log *log,
vo_opengl: refactor tex_upload to ra_buf_pool Also refactors the usage of tex_upload to make ra_tex_upload_pbo a RA-internal thing again. ra_buf_pool has the main advantage of being dynamically sized depending on buf_poll, so for OpenGL we'll end up only using one buffer (when not persistently mapping) - while for vulkan we'll use as many as necessary, which depends on the swapchain depth anyway.
2017-08-19 02:33:40 +00:00
struct osd_state *osd)
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
{
struct mpgl_osd *ctx = talloc_ptrtype(NULL, ctx);
*ctx = (struct mpgl_osd) {
gl_osd: mp_msg conversion
2013-09-11 23:33:33 +00:00
.log = log,
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
.osd = osd,
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
.ra = ra,
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
.change_flag = true,
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
.scratch = talloc_zero_size(ctx, 1),
};
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
ctx->fmt_table[SUBBITMAP_LIBASS] = ra_find_unorm_format(ra, 1, 1);
sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRA This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
2022-01-11 20:03:27 +00:00
ctx->fmt_table[SUBBITMAP_BGRA] = ra_find_unorm_format(ra, 1, 4);
vo_opengl: remove requirement for RG textures Features not supported are disabled (although with a misleading error message).
2014-12-16 17:55:02 +00:00
vo_opengl: remove OSD bitmap packing It's packed in the OSD common layer already.
2016-07-01 17:47:31 +00:00
for (int n = 0; n < MAX_OSD_PARTS; n++)
ctx->parts[n] = talloc_zero(ctx, struct mpgl_osd_part);
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 17:25:18 +00:00
for (int n = 0; n < SUBBITMAP_COUNT; n++)
vo_opengl: reorganize texture format handling This merges all knowledge about texture format into a central table. Most of the work done here is actually identifying which formats exactly are supported by OpenGL(ES) under which circumstances, and keeping this information in the format table in a somewhat declarative way. (Although only to the extend needed by mpv.) In particular, ES and float formats are a horrible mess. Again this is a big refactor that might cause regression on "obscure" configurations.
2016-05-12 18:08:49 +00:00
ctx->formats[n] = !!ctx->fmt_table[n];
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 17:25:18 +00:00
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
return ctx;
}
void mpgl_osd_destroy(struct mpgl_osd *ctx)
{
video/out: change aspects of OSD handling Let the VOs draw the OSD on their own, instead of making OSD drawing a separate VO driver call. Further, let it be the VOs responsibility to request subtitles with the correct PTS. We also basically allow the VO to request OSD/subtitles at any time. OSX changes untested.
2014-06-15 18:46:57 +00:00
if (!ctx)
return;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
for (int n = 0; n < MAX_OSD_PARTS; n++) {
struct mpgl_osd_part *p = ctx->parts[n];
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
ra_tex_free(ctx->ra, &p->texture);
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
}
talloc_free(ctx);
}
sub, vo_opengl: use packed sub-bitmaps directly if available The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
2016-06-17 21:11:05 +00:00
static int next_pow2(int v)
{
for (int x = 0; x < 30; x++) {
if ((1 << x) >= v)
return 1 << x;
}
return INT_MAX;
}
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
static bool upload_osd(struct mpgl_osd *ctx, struct mpgl_osd_part *osd,
struct sub_bitmaps *imgs)
{
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
struct ra *ra = ctx->ra;
vo_opengl: remove caching GL_MAX_TEXTURE_SIZE value No real need to cache this, and we need fewer fields in the OSD part struct. Also add logging for when the OSD texture is reallocated.
2016-07-03 15:33:59 +00:00
bool ok = false;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
vo_opengl: remove OSD bitmap packing It's packed in the OSD common layer already.
2016-07-01 17:47:31 +00:00
assert(imgs->packed);
int req_w = next_pow2(imgs->packed_w);
int req_h = next_pow2(imgs->packed_h);
sub, vo_opengl: use packed sub-bitmaps directly if available The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
2016-06-17 21:11:05 +00:00
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
const struct ra_format *fmt = ctx->fmt_table[imgs->format];
vo_opengl: reorganize texture format handling This merges all knowledge about texture format into a central table. Most of the work done here is actually identifying which formats exactly are supported by OpenGL(ES) under which circumstances, and keeping this information in the format table in a somewhat declarative way. (Although only to the extend needed by mpv.) In particular, ES and float formats are a horrible mess. Again this is a big refactor that might cause regression on "obscure" configurations.
2016-05-12 18:08:49 +00:00
assert(fmt);
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
if (!osd->texture || req_w > osd->w || req_h > osd->h ||
osd->format != imgs->format)
{
ra_tex_free(ra, &osd->texture);
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
osd->format = imgs->format;
Replace uses of FFMIN/MAX with MPMIN/MAX And remove libavutil includes where possible.
2019-10-31 10:24:20 +00:00
osd->w = MPMAX(32, req_w);
osd->h = MPMAX(32, req_h);
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
vo_opengl: remove caching GL_MAX_TEXTURE_SIZE value No real need to cache this, and we need fewer fields in the OSD part struct. Also add logging for when the OSD texture is reallocated.
2016-07-03 15:33:59 +00:00
MP_VERBOSE(ctx, "Reallocating OSD texture to %dx%d.\n", osd->w, osd->h);
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
if (osd->w > ra->max_texture_wh || osd->h > ra->max_texture_wh) {
vo_opengl: remove caching GL_MAX_TEXTURE_SIZE value No real need to cache this, and we need fewer fields in the OSD part struct. Also add logging for when the OSD texture is reallocated.
2016-07-03 15:33:59 +00:00
MP_ERR(ctx, "OSD bitmaps do not fit on a surface with the maximum "
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
"supported size %dx%d.\n", ra->max_texture_wh,
ra->max_texture_wh);
vo_opengl: remove caching GL_MAX_TEXTURE_SIZE value No real need to cache this, and we need fewer fields in the OSD part struct. Also add logging for when the OSD texture is reallocated.
2016-07-03 15:33:59 +00:00
goto done;
}
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
struct ra_tex_params params = {
.dimensions = 2,
.w = osd->w,
.h = osd->h,
.d = 1,
.format = fmt,
.render_src = true,
.src_linear = true,
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
.host_mutable = true,
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
};
osd->texture = ra_tex_create(ra, &params);
if (!osd->texture)
goto done;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
}
vo_opengl: refactor RA texture and buffer updates - tex_uploads args are moved to a struct - the ability to directly upload texture data without going through a buffer is made explicit - the concept of buffer updates and buffer polling is made more explicit and generalized to buf_update as well (not just mapped buffers) - the ability to call tex_upload/buf_update on a tex/buf is made explicit during tex/buf creation - uploading from buffers now uses an explicit offset instead of implicitly comparing *src against buf->data, because not all buffers may actually be persistently mapped - the initial_data = immutable requirement is dropped. (May be re-added later for D3D11 if that ever becomes a thing) This change helps the vulkan abstraction immensely and also helps move common code (like the PBO pooling) out of ra_gl and into the opengl/utils.c This also technically has the side-benefit / side-constraint of using PBOs for OSD texture uploads as well, which actually seems to help performance on machines where --opengl-pbo is faster than the naive code path. Because of this, I decided to hook up the OSD code to the opengl-pbo option as well. One drawback of this refactor is that the GL_STREAM_COPY hack for texture uploads "got lost", but I think I'm happy with that going away anyway since DR almost fully deprecates it, and it's not the "right thing" anyway - but instead an nvidia-only hack to make this stuff work somewhat better on NUMA systems with discrete GPUs. Another change is that due to the way fencing works with ra_buf (we get one fence per ra_buf per upload) we have to use multiple ra_bufs instead of offsets into a shared buffer. But for OpenGL this is probably better anyway. It's possible that in future, we could support having independent “buffer slices” (each with their own fence/sync object), but this would be an optimization more than anything. I also think that we could address the underlying problem (memory closeness) differently by making the ra_vk memory allocator smart enough to chunk together allocations under the hood.
2017-08-16 20:13:51 +00:00
struct ra_tex_upload_params params = {
.tex = osd->texture,
.src = imgs->packed->planes[0],
.invalidate = true,
.rc = &(struct mp_rect){0, 0, imgs->packed_w, imgs->packed_h},
.stride = imgs->packed->stride[0],
};
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
vo_opengl: refactor tex_upload to ra_buf_pool Also refactors the usage of tex_upload to make ra_tex_upload_pbo a RA-internal thing again. ra_buf_pool has the main advantage of being dynamically sized depending on buf_poll, so for OpenGL we'll end up only using one buffer (when not persistently mapping) - while for vulkan we'll use as many as necessary, which depends on the swapchain depth anyway.
2017-08-19 02:33:40 +00:00
ok = ra->fns->tex_upload(ra, &params);
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
vo_opengl: remove caching GL_MAX_TEXTURE_SIZE value No real need to cache this, and we need fewer fields in the OSD part struct. Also add logging for when the OSD texture is reallocated.
2016-07-03 15:33:59 +00:00
done:
return ok;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
static void gen_osd_cb(void *pctx, struct sub_bitmaps *imgs)
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
{
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
struct mpgl_osd *ctx = pctx;
VO, sub: refactor Remove VFCTRL_DRAW_OSD, VFCAP_EOSD_FILTER, VFCAP_EOSD_RGBA, VFCAP_EOSD, VOCTRL_DRAW_EOSD, VOCTRL_GET_EOSD_RES, VOCTRL_QUERY_EOSD_FORMAT. Remove draw_osd_with_eosd(), which rendered the OSD by calling VOCTRL_DRAW_EOSD. Change VOs to call osd_draw() directly, which takes a callback as argument. (This basically works like the old OSD API, except multiple OSD bitmap formats are supported and caching is possible.) Remove all mentions of "eosd". It's simply "osd" now. Make OSD size per-OSD-object, as they can be different when using vf_sub. Include display_par/video_par in resolution change detection. Fix the issue with margin borders in vo_corevideo.
2012-10-19 17:25:18 +00:00
if (imgs->num_parts == 0 || !ctx->formats[imgs->format])
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
return;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
struct mpgl_osd_part *osd = ctx->parts[imgs->render_index];
sub, vo_opengl: use packed sub-bitmaps directly if available The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
2016-06-17 21:11:05 +00:00
bool ok = true;
osd: simplify an aspect of change detection handling There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
2015-03-18 11:33:14 +00:00
if (imgs->change_id != osd->change_id) {
if (!upload_osd(ctx, osd, imgs))
sub, vo_opengl: use packed sub-bitmaps directly if available The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
2016-06-17 21:11:05 +00:00
ok = false;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
osd: simplify an aspect of change detection handling There was a somewhat obscure optimization in the OSD and subtitle rendering path: if only the position of the sub-images changed, and not the actual image data, uploading of the image data could be skipped. In theory, this could speed up things like scrolling subtitles. But it turns out that even in the rare cases subtitles have such scrolls or axis-aligned movement, modern libass rarely signals this kind of change. Possibly this is because of sub-pixel handling and such, which break this. As such, it's a worthless optimization and just introduces additional complexity and subtle bugs (especially in cases libass does the opposite: incorrectly signaling a position change only, which happened before). Remove this optimization, and rename bitmap_pos_id to change_id.
2015-03-18 11:33:14 +00:00
osd->change_id = imgs->change_id;
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
ctx->change_flag = true;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
}
sub, vo_opengl: use packed sub-bitmaps directly if available The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
2016-06-17 21:11:05 +00:00
osd->num_subparts = ok ? imgs->num_parts : 0;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
MP_TARRAY_GROW(osd, osd->subparts, osd->num_subparts);
memcpy(osd->subparts, imgs->parts,
osd->num_subparts * sizeof(osd->subparts[0]));
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
}
vo_opengl: osd: use new VAO mechanism In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
2017-07-22 19:53:50 +00:00
bool mpgl_osd_draw_prepare(struct mpgl_osd *ctx, int index,
struct gl_shader_cache *sc)
{
assert(index >= 0 && index < MAX_OSD_PARTS);
struct mpgl_osd_part *part = ctx->parts[index];
enum sub_bitmap_format fmt = part->format;
vo_gpu: fix segfault when OSD tex creation fails If !osd->texture, then mpgl_osd_draw_prepare fails.
2018-11-17 16:12:42 +00:00
if (!fmt || !part->num_subparts || !part->texture)
vo_opengl: osd: use new VAO mechanism In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
2017-07-22 19:53:50 +00:00
return false;
vo_opengl: make OSD code use ra for textures This requires a silly extension to ra_fns.tex_upload: since the OSD texture can be much larger than the actual OSD image data to upload, a mechanism for uploading only to a small part of the texture is needed. Otherwise, we'd have to realloc/copy the data, just to pad it, and then pay for uploading the padding too. The RA_TEX_UPLOAD_DISCARD flag is not interpreted by GL (not sure how you'd tell GL about this), but it clarifies the API and might be helpful if we support other backend APIs in the future.
2017-08-05 11:39:20 +00:00
gl_sc_uniform_texture(sc, "osdtex", part->texture);
vo_opengl: osd: use new VAO mechanism In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
2017-07-22 19:53:50 +00:00
switch (fmt) {
sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRA This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
2022-01-11 20:03:27 +00:00
case SUBBITMAP_BGRA: {
vo_opengl: osd: use new VAO mechanism In addition to using the new VAO mechanism introduced in the previous commit, this tries to keep the OSD code self-contained. This doesn't work all too well (because of the pass and CMS stuff), but it's still better than before.
2017-07-22 19:53:50 +00:00
GLSL(color = texture(osdtex, texcoord).bgra;)
break;
}
case SUBBITMAP_LIBASS: {
GLSL(color =
vec4(ass_color.rgb, ass_color.a * texture(osdtex, texcoord).r);)
break;
}
default:
abort();
}
return true;
}
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
static void write_quad(struct vertex *va, struct gl_transform t,
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
float x0, float y0, float x1, float y1,
float tx0, float ty0, float tx1, float ty1,
vo_opengl: use triangle strip for video A small simplification. Couldn't be done before, because it was also used by the OSD code, which required disjoint quads in a single draw call. Also mess with the unrelated code in gl_osd.c to simplify it a little as well.
2015-01-30 13:02:09 +00:00
float tex_w, float tex_h, const uint8_t color[4])
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
{
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
gl_transform_vec(t, &x0, &y0);
gl_transform_vec(t, &x1, &y1);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
#define COLOR_INIT {color[0], color[1], color[2], color[3]}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
va[0] = (struct vertex){ {x0, y0}, {tx0 / tex_w, ty0 / tex_h}, COLOR_INIT };
va[1] = (struct vertex){ {x0, y1}, {tx0 / tex_w, ty1 / tex_h}, COLOR_INIT };
va[2] = (struct vertex){ {x1, y0}, {tx1 / tex_w, ty0 / tex_h}, COLOR_INIT };
va[3] = (struct vertex){ {x1, y1}, {tx1 / tex_w, ty1 / tex_h}, COLOR_INIT };
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
va[4] = va[2];
va[5] = va[1];
#undef COLOR_INIT
}
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
static void generate_verts(struct mpgl_osd_part *part, struct gl_transform t)
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
{
vo_gpu: osd: simplify some code Coverity complains about this, but it's probably a false positive. Anyway, rewrite it in a slightly more readable way. Now it's more obvious that it is correct.
2017-10-27 12:19:57 +00:00
MP_TARRAY_GROW(part, part->vertices,
part->num_vertices + part->num_subparts * 6);
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
for (int n = 0; n < part->num_subparts; n++) {
struct sub_bitmap *b = &part->subparts[n];
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
struct vertex *va = &part->vertices[part->num_vertices];
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
// NOTE: the blend color is used with SUBBITMAP_LIBASS only, so it
// doesn't matter that we upload garbage for the other formats
uint32_t c = b->libass.color;
uint8_t color[4] = { c >> 24, (c >> 16) & 0xff,
(c >> 8) & 0xff, 255 - (c & 0xff) };
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
vo_gpu: osd: simplify some code Coverity complains about this, but it's probably a false positive. Anyway, rewrite it in a slightly more readable way. Now it's more obvious that it is correct.
2017-10-27 12:19:57 +00:00
write_quad(va, t,
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
b->x, b->y, b->x + b->dw, b->y + b->dh,
sub, vo_opengl: use packed sub-bitmaps directly if available The previous few commits changed sd_lavc.c's output to packed RGB sub- images. In particular, this means all sub-bitmaps are part of a larger, single bitmap. Change the vo_opengl OSD code such that it can make use of this, and upload the pre-packed image, instead of packing and copying them again. This complicates the upload code a bit (4 code paths due to messy PBO handling). The plan is to make sub-bitmaps always packed, but some more work is required to reach this point. The plan is to pack libass images as well. Since this implies a copy, this will make it easy to refcount the result. (This is all targeted towards vo_opengl. Other VOs, vo_xv, vo_x11, and vo_wayland in particular, will become less efficient. Although at least vo_vdpau and vo_direct3d could be switched to the new method as well.)
2016-06-17 21:11:05 +00:00
b->src_x, b->src_y, b->src_x + b->w, b->src_y + b->h,
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
part->w, part->h, color);
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
vo_gpu: osd: simplify some code Coverity complains about this, but it's probably a false positive. Anyway, rewrite it in a slightly more readable way. Now it's more obvious that it is correct.
2017-10-27 12:19:57 +00:00
part->num_vertices += 6;
}
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
}
// number of screen divisions per axis (x=0, y=1) for the current 3D mode
static void get_3d_side_by_side(int stereo_mode, int div[2])
{
div[0] = div[1] = 1;
switch (stereo_mode) {
case MP_STEREO3D_SBS2L:
case MP_STEREO3D_SBS2R: div[0] = 2; break;
case MP_STEREO3D_AB2R:
case MP_STEREO3D_AB2L: div[1] = 2; break;
}
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
}
vo_opengl: simplify mirroring and fix it if glBlitFramebuffer is used The vp_w/vp_h variables and parameters were not really used anymore (they were redundant with ra_tex w/h) - but vp_h was still used to identify whether rendering should be done mirrored. Simplify this by adding a fbodst struct (some bad naming), which contains the render target texture, and some parameters how it should be rendered to (for now only flipping). It would not be appropriate to make this a member of ra_tex, so it's a separate struct. Introduces a weird regression for the first frame rendered after interpolation is toggled at runtime, but seems to work otherwise. This is possibly due to the change that blit() now mirrors, instead of just copying. (This is also why ra_fns.blit is changed.) Fixes #4719.
2017-08-07 14:44:15 +00:00
void mpgl_osd_draw_finish(struct mpgl_osd *ctx, int index,
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
struct gl_shader_cache *sc, struct ra_fbo fbo)
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
{
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
struct mpgl_osd_part *part = ctx->parts[index];
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
int div[2];
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
get_3d_side_by_side(ctx->stereo_mode, div);
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
part->num_vertices = 0;
vo_opengl: move glViewport call closer to draw call
2015-03-16 19:10:48 +00:00
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
for (int x = 0; x < div[0]; x++) {
for (int y = 0; y < div[1]; y++) {
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
struct gl_transform t;
vo_gpu: simplify structs / names Due to the plethora of historical baggage from different eras getting confusing, I decided to simplify and unify the struct organization and naming scheme. Structs that got renamed: 1. fbodst -> ra_fbo (and moved to gpu/context.h) 2. fbotex -> removed (redundant after 2af2fa7a) 3. fbosurface -> surface 4. img_tex -> image In addition to these structs being renamed, all of the names have been made consistent. The new scheme is as follows: struct image img; struct ra_tex *tex; struct ra_fbo fbo; This also affects derived names, e.g. indirect_fbo -> indirect_tex. Notably also, finish_pass_fbo -> finish_pass_tex and finish_pass_direct -> finish_pass_fbo. The new equivalent of fbotex_change() is called ra_tex_resize(). This commit (should) contain no logic changes, just renaming a bunch of crap.
2017-09-20 08:45:33 +00:00
gl_transform_ortho_fbo(&t, fbo);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl, osd: allow osc.lua to react faster on resizes Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
2016-03-21 21:23:41 +00:00
float a_x = ctx->osd_res.w * x;
float a_y = ctx->osd_res.h * y;
vo_opengl: replace float array with a struct Slightly less painful, because C arrays suck.
2015-03-13 20:14:18 +00:00
t.t[0] += a_x * t.m[0][0] + a_y * t.m[1][0];
t.t[1] += a_x * t.m[0][1] + a_y * t.m[1][1];
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
generate_verts(part, t);
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
}
}
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
const int *factors = &blend_factors[part->format][0];
vo_opengl: move shader handling to ra Now all GL-specifics of shader compilation are abstracted through ra. Of course we still have everything hardcoded to GLSL - that isn't going to change. Some things will probably change later - in particular, the way we pass uniforms and textures to the shader. Currently, there is a confusing mismatch between "primitive" uniforms like floats, and others like textures. Also, SSBOs are not abstracted yet.
2017-08-05 12:20:14 +00:00
gl_sc_blend(sc, factors[0], factors[1], factors[2], factors[3]);
vo_opengl: osd: refactor and simplify Reduce this to 1 draw call per OSD pass. This removes the need for some annoying special handling regarding 3D video support (we supported duplicating the OSD/subtitles for side-by-side 3D output etc.). Remove the unneeded texture sampler uniform thing.
2017-07-22 19:46:59 +00:00
vo_gpu: invalidate fbotex before drawing Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
2017-08-18 00:31:58 +00:00
gl_sc_dispatch_draw(sc, fbo.tex, false, vertex_vao, MP_ARRAY_SIZE(vertex_vao),
vo_gpu: make the vertex attribs dynamic This has several advantages: 1. no more redundant texcoords when we don't need them 2. no more arbitrary limit on how many textures we can bind 3. (that extends to user shaders as well) 4. no more arbitrary limits on tscale radius To realize this, the VAO was moved from a hacky stateful approach (gl_sc_set_vertex_attribs) - which always bothered me since it was required for compute shaders as well even though they ignored it - to be a proper parameter of gl_sc_dispatch_draw, and internally plumbed into gl_sc_generate, which will make a (properly mangled) deep copy into params.vertex_attribs.
2017-09-27 22:07:42 +00:00
sizeof(struct vertex), part->vertices, part->num_vertices);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
}
vo_opengl: move remaining OSD rendering parts to gl_osd.c Reduces the size of gl_video.c a bit further. This also uses a separate vertex array object for OSD elements, so the video one can be simplified slightly. OSD shader generation is still in gl_video.c, which leads to the strange additional parameter to mpgl_osd_init(). The issue is that video parameters influence the OSD shader (????), and also OSD needs to go through the screen colormanagement.
2015-01-29 17:29:28 +00:00
vo_opengl, osd: allow osc.lua to react faster on resizes Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
2016-03-21 21:23:41 +00:00
static void set_res(struct mpgl_osd *ctx, struct mp_osd_res res, int stereo_mode)
{
int div[2];
get_3d_side_by_side(stereo_mode, div);
res.w /= div[0];
res.h /= div[1];
ctx->osd_res = res;
}
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
void mpgl_osd_generate(struct mpgl_osd *ctx, struct mp_osd_res res, double pts,
vo_opengl: draw subtitles directly onto the video This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
2015-03-23 01:42:19 +00:00
int stereo_mode, int draw_flags)
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
{
for (int n = 0; n < MAX_OSD_PARTS; n++)
ctx->parts[n]->num_subparts = 0;
vo_opengl, osd: allow osc.lua to react faster on resizes Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
2016-03-21 21:23:41 +00:00
set_res(ctx, res, stereo_mode);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
vo_opengl, osd: allow osc.lua to react faster on resizes Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
2016-03-21 21:23:41 +00:00
osd_draw(ctx->osd, ctx->osd_res, pts, draw_flags, ctx->formats, gen_osd_cb, ctx);
vo_opengl: refactor shader generation (part 1) The basic idea is to use dynamically generated shaders instead of a single monolithic file + a ton of ifdefs. Instead of having to setup every aspect of it separately (like compiling shaders, setting uniforms, perfoming the actual rendering steps, the GLSL parts), we generate the GLSL on the fly, and perform the rendering at the same time. The GLSL is regenerated every frame, but the actual compiled OpenGL-level shaders are cached, which makes it fast again. Almost all logic can be in a single place. The new code is significantly more flexible, which allows us to improve the code clarity, performance and add more features easily. This commit is incomplete. It drops almost all previous code, and readds only the most important things (some of them actually buggy). The next commit will complete it - it's separate to preserve authorship information.
2015-03-12 20:57:54 +00:00
ctx->stereo_mode = stereo_mode;
vo_rpi: redraw subtitles only on change Since vo_rpi uses MMAL for video output, which is completely independent from the GLES overlay, we can just not redraw the GLES screen if subtitles do not change. (As a furhter optimization, the dispmanx overlay could be removed if nothing is visible. But I'm not sure if adding and removing the overlay frequently is a good idea for performance, so this could just as well go the other way.)
2015-08-18 20:59:22 +00:00
// Parts going away does not necessarily result in gen_osd_cb() being called
// (not even with num_parts==0), so check this separately.
for (int n = 0; n < MAX_OSD_PARTS; n++) {
struct mpgl_osd_part *part = ctx->parts[n];
if (part->num_subparts != part->prev_num_subparts)
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
ctx->change_flag = true;
vo_rpi: redraw subtitles only on change Since vo_rpi uses MMAL for video output, which is completely independent from the GLES overlay, we can just not redraw the GLES screen if subtitles do not change. (As a furhter optimization, the dispmanx overlay could be removed if nothing is visible. But I'm not sure if adding and removing the overlay frequently is a good idea for performance, so this could just as well go the other way.)
2015-08-18 20:59:22 +00:00
part->prev_num_subparts = part->num_subparts;
}
}
vo_opengl, osd: allow osc.lua to react faster on resizes Glitches when resizing are still possible, but are reduced. Other VOs could support this too, but don't need to do so. (Totally avoiding glitches would be much more effort, and probably not worth the trouble. How about you just watch the video the player is playing, instead of spending your time resizing the window.)
2016-03-21 21:23:41 +00:00
// See osd_resize() for remarks. This function is an optional optimization too.
void mpgl_osd_resize(struct mpgl_osd *ctx, struct mp_osd_res res, int stereo_mode)
{
set_res(ctx, res, stereo_mode);
osd_resize(ctx->osd, ctx->osd_res);
}
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
bool mpgl_osd_check_change(struct mpgl_osd *ctx, struct mp_osd_res *res,
double pts)
vo_rpi: redraw subtitles only on change Since vo_rpi uses MMAL for video output, which is completely independent from the GLES overlay, we can just not redraw the GLES screen if subtitles do not change. (As a furhter optimization, the dispmanx overlay could be removed if nothing is visible. But I'm not sure if adding and removing the overlay frequently is a good idea for performance, so this could just as well go the other way.)
2015-08-18 20:59:22 +00:00
{
vo_rpi: fix operation Commit 697c4389a9e6 worked "almost". I couldn't test it at the time.
2017-08-15 17:12:39 +00:00
ctx->change_flag = false;
rpi: fix build Runtime untested, because I get this: [vo/rpi] Could not get DISPMANX objects. This happened even when building older git versions, and on a RPI image that hasn't changed in the recent years. I don't know how to make this POS work again, so I guess if there's a bug in the new code, it will remain broken.
2017-08-11 11:02:13 +00:00
mpgl_osd_generate(ctx, *res, pts, 0, 0);
return ctx->change_flag;
vo_gl3: move OSD code to gl_osd.c Other OpenGL-using VOs can use this. gl_osd.c includes some code for vo_gl.c. The next commit actually makes use of it.
2012-10-03 16:25:41 +00:00
}