summaryrefslogtreecommitdiffstats
path: root/libvo/vo_direct3d.c
Commit message (Collapse)AuthorAgeFilesLines
* VO, sub: refactorwm42012-10-241-45/+53
| | | | | | | | | | | | | | | | | | 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.
* sub: switch to premultiplied alphawm42012-10-161-0/+5
| | | | | | | | | | Fixes problems with ugly borders. Note that at least in the DVD sub case, we could have just set all transparent pixels to black to solve this. vo_direct3d.c change untested, because mingw is a miserable pile of crap.
* sub, VO: remove vo_osd_resized() functionwm42012-10-161-2/+0
| | | | | | | | | | | VOs which could render the OSD in window size (as opposed to video size, like vo_xv) and which could cache the OSD called this when the window size changed. This was needed, because VOs used another OSD function to check whether the OSD changed before passing the new window size to the OSD code. This was really just an artifact of OSD change detection, and now that the affected VOs use the new OSD rendering API, it's done automatically.
* vo_direct3d: use new OSD APIwm42012-10-161-287/+145
|
* sub: remove logic for disabling hinting on scaled EOSDwm42012-10-161-1/+1
| | | | | | | | | | | This was an extremely obscure setting, as it was used only with vo_gl if its scaled-osd suboption was used. If you really want this, you can set the desired ass-hinting value directly, and there will be literally no loss in functionality. Note that this didn't actually test whether the EOSD was scaled. Basically, it only checked whether vo_gl had the scaled-osd suboption set.
* win32: fix compilation on MinGWwm42012-08-071-1/+1
| | | | | | | | | | | | | | | The commit 74df1d8e05aa2 (and f752212c62353) replaced the configure endian check with byte order macros defined by standard headers. It turns out that MinGW-w64 actually doesn't define these macros in the sys/types.h system header. (I assumed it does, because a quick test seemed to work. But that was because gcc -W -Wall doesn't warn against undefined macros. You need -Wundef for that.) MinGW-w64 has a sys/params.h header defining these macros, but sys/types.h doesn't include it, so it's useless without special casing the mplayer code. Add a hack top configure instead. Define the macros directly, and assume MinGW-w64 only works on little endian machines. The other changes are basically random typos and superficial oversights.
* VO: remove VO direct renderingwm42012-08-021-4/+0
| | | | | | | | | | | | | | | | | | | This was disabled by default, and could be enabled with -dr. It was disabled by default because it was buggy: there were issues with OSD corruption. It wasn't entirely sane for OpenGL based VOs either. OpenGL can chose to drop mapped pixel buffer objects, requiring the application to map and fill the buffer again. But there was no mechanism in mplayer to fill the lost buffer again. (It seems this rarely happened in practice, though.) On the other side, users liked the --dr flag, because it promised them more speed. I'm not sure if it actually helped with speed, but it's unlikely it had any real advantages on modern systems. In order to evade the --dr cargo culting in mplayer config files, it's best to get rid of it.
* osd: minor simplification of vo_osd_changed()wm42012-08-011-1/+1
| | | | | | | | | | | | | | | | | | vo_osd_changed() was a weird function: it was used both to query and mutate state, which is a bad combination. The VOs used it to query and reset the state, and the mplayer frontend mostly used it to set the state. In some cases, the frontend did both (that code used a variable "int hack" to backup the state and set it again). Simplify it and make the VOs use a vo_osd_has_changed() function to query whether the OSD bitmaps have to be recreated. vo_osd_changed() on the other hand is now used to update state only. The OSD change state is reset when osd_draw_text() is called. Update vo_corevideo.m to use vo_osd_resized() as well (forgotten change from libass-OSD merge). Simplify osd_set_text() and its usages.
* osd: use libass for OSD renderingwm42012-07-281-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OSD will now be rendered with libass. The old rendering code, which used freetype/fontconfig and did text layout manually, is disabled. To re-enable the old code, use the --disable-libass-osd configure switch. Some switches do nothing with the new code enabled, such as -subalign, -sub-bg-alpha, -sub-bg-color, and many more. (The reason is mostly that the code for rendering unstyled subtitles with libass doesn't make any attempts to support them. Some of them could be supported in theory.) Teletext rendering is not implemented in the new OSD rendering code. I don't have any teletext sources for testing, and since teletext is being phased out world-wide, the need for this is questionable. Note that rendering is extremely inefficient, mostly because the libass output is blended with the extremely strange mplayer OSD format. This could be improved at a later point. Remove most OSD rendering from vo_aa.c, because that was extremely hacky, can't be made work with osd_libass, and didn't work anyway in my tests. Internally, some cleanup is done. Subtitle and OSD related variable declarations were literally all over the place. Move them to sub.h and sub.c, which were hoarding most of these declarations already. Make the player core in mplayer.c free of concerns like bitmap font loading. The old OSD rendering code has been moved to osd_ft.c. The font_load.c and font_load_ft.c are only needed and compiled if the old OSD rendering code is configured.
* win32: move global variables into a struct & some refactoringwm42012-04-141-20/+12
| | | | | | | | | | This reflects the changes done to x11_common in mplayer2 some years ago. It makes it possible to open multiple VOs at once. The removed defines are probably for ancient versions of MinGW with incomplete headers. Remove some minor code duplication.
* vo_direct3d: fix crash when using RGB formatswm42012-03-261-5/+5
| | | | | | | | | | | | | The function mp_get_yuv2rgb_coeffs() expects valid values for input_bits. When using RGB formats, input_bits is outside the range of what mp_get_yuv2rgb_coeffs() expects. This doesn't matter since we don't use the result of that function in the RGB case, but it triggered an assertion. This is a regression from commit a8168102668337f3c1, "vo_gl: improve 10-bit YUV->RGB conversion accuracy slightly".
* vo_direct3d: fix bug in screenshot code with some pixel formatswm42012-03-171-1/+1
| | | | | | A typo caused the height of the image copy to be incorrectly calculated with some less common pixel formats, when X chroma shift != Y chroma shift.
* vo_direct3d: fix crash when repeatedly reinitializing an uncooperative devicewm42012-03-171-2/+4
|
* vo_direct3d: stop D3D from switching the FPU to single precision modewm42012-03-171-1/+2
| | | | | | | | | | | Add the flag D3DCREATE_FPU_PRESERVE, which tells Direct3D not to switch the FPU to single precision mode. Single precision mode would mean that all floating point calculations are done in float precision, even if using double variables. The MSDN documentation seems to discourage use of this flag with scary warnings about bad performance and stability, but I suspect in practice switching off this completely unreasonable behavior is fine.
* vo: fix EOSD change detectionwm42012-03-171-29/+35
| | | | | | | | | | | | | | | | The case when the EOSD sub-images changed position, but didn't need re-upload, wasn't handled correctly. If a subtitle script made text move over the screen (without any other changes), the subtitle display wasn't updated. vo_vdpau was not affected, because vdpau directly reads the sub-image positions on every frame. The fix could be simpler. It could recreate the vertex array every frame. This commit keeps the optimization that nothing is done when the libass native change detection doesn't report any change. Maybe this optimization isn't worth doing, since recreating the vertex array is relatively cheap compared to amount of work required to render complicated subtitles. The eosd_packer_generate function returning 3 boolean flags is ugly.
* vo_direct3d: implement screenshotswm42012-03-171-0/+186
| | | | | | | | | | | | | | | | | | | | There are 4 code paths when taking a screenshot: - textured rendering mode - StretchRect rendering mode with planar formats - StretchRect with packed formats - full-window screenshot mode The implementation of the full-window mode (capturing the window contents, instead of the video) is very inefficient: it will create a surface of desktop size, copy the desktop contents, allocate a new memory image, and copy in the window contents. The code in screenshot.c will (as of now) allocate and convert the image from BGR to RGB, and allocate a destination buffer for the libavcodec PNG writer. If parts of the mplayer window are obscured, the full-window mode wil contain these parts as seen on the screen. Parts of the window that are outside the bounds of the desktop are clipped away. It is not known whether full-window mode works on multi-monitor setups.
* vo_direct3d: fix dealing with uncooperative deviceswm42012-03-171-6/+25
| | | | | | | | | | | | | | | | | If the Direct3D device is "lost" (e,g, when minimizing mplayer, or when another application uses Direct3D exclusive mode), we free it and try to recrate the device. This can fail, and may fail for an extended period of time, until D3D is available again and the device can be created. So we basically have to provide all VO functionality while d3d_device is NULL. Don't terminate if device creation fails, and re-add the NULL checks that were removed in the commit "vo_direct3d: refactor D3D initialization and reconfigure code". If mplayer calls the VO's config() while the D3D device can not be created, the VO will return an error and mplayer will terminate. config() is typically called when new files are played, when ordered chapter boundaries are crossed, or on other events.
* vo_direct3d: add hack for using 2 channel textures for 10 bit pixel formatswm42012-03-171-5/+75
| | | | | | | | | | | | | | | | This actually applies to YUV formats with 9-16 bit depths. This hack is disabled by default, and the VO will use 16 bit textures normally. It can be enabled by passing the no16bit-textures option is passed to vo_direct3d. Then the VO will use D3DFMT_A8L8 as texture formats for the YUV plane (instead of D3DFMT_L16), and compute the sampled two color values back into one. In some cases it might be undesireable to use 16 bit texture formats. At least some OpenGL drivers on Linux (Mesa + Intel) round values sampled from 16 bit textures back into 8 bit, which loses 8 from 10 bit color information when playing 10 bit formats. It is unknown whether there are D3D9 drivers which do this, so this commit might be removed later.
* vo_direct3d: add some debugging optionswm42012-03-171-12/+53
| | | | | This is for testing. Most of these make no sense, or even if they do, might not improve anything.
* vo_direct3d: refactor D3D initialization and reconfigure codewm42012-03-171-171/+111
| | | | | | | | | | | | | | | | | | | | | | | | | This simplifies the code and removes code duplication. There should be no actual semantic differences to the previous code. The only exception is that the new code doesn't query the display adapter's desktop pixel format on backbuffer resizing anymore. In my opinion the format can never change anyway, and if it does, it will cause the D3D device to become "uncooperative" and we will recreate it in flip_page. Remove attempts to handle d3d_device when it's NULL (outside of the initialization paths). d3d_device can only be NULL if recreating a D3D device, that was in "incooperative" state, fails. The current (and previous) code seems to assume that this never happens. It is unlikely that these NULL checks improved correct operation in any way, or at least they won't anymore after the recent changes done to the code. If it should be possible that a device can't be reset/recreated for a while (during display resolution changes? when another D3D application is in fullscreen mode?), another solution has to be found. It is unknown why the code recreates the IDirect3D9 interface when the device was uncooperative. At least on Windows XP + reference rasterizer, resuming works without recreating it. Leave this code just in case.
* vo_direct3d: disable using shaders by default, and add direct3d_shaders VOwm42012-03-171-10/+42
| | | | | | | | | | | | | | Now using the "direct3d" VO will never make use of shaders. Instead, users are supposed to use the direct3d_shaders VO entry, which is exactly the same as direct3d, except with shaders enabled by default. "direct3d" always uses the Direct3D StretcRect API call to render videos. Playing formats not supported by this function will force mplayer to insert a scale filter to convert video frames in software. "direct3d_shaders" prefers shader color conversion, but can fall back to StretchRect if the format can be handled. (This happens only with some insignificant packed YUV formats.)
* vo_direct3d: use new VO API, and do some minor reformattingwm42012-03-171-269/+298
| | | | | | | | | | | | | | | | The minor reformats are mainly about adding more line breaks to fit a 80 column limit. Using the new VO API implies removing all non-const global variables (because that is one important goal of the new API), so do that as well. The code already had all variables in a context struct, and changing all the functions to pass this context struct along was all what had to be done. Also handle redrawing properly: if something changes that requires an immediate redrawing operation (e.g. setting video equalizers when paused or when playback is slow), vo->want_redraw should be set, instead of redrawing on your own.
* vo_direct3d: implement YUV conversion using shaderswm42012-03-171-192/+680
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the 3D rendering functions and shaders to render the video frame. This is very similar to vo_gl. Most planar formats with varying chroma shifts and bit depths are supported (including 10 bit), as well as some RGB formats. The old code that used D3D's StretchRect function is still available, but will by default be used with the least priority. Also implement video equalizers and colorspace selection. These use the same code as vo_gl and vo_vdpau, and are available only if shader YUV conversion is active. The rendering is extremely simple and naive, there are no filters etc. Since compiling shaders seems to require the 500 MB DirectX SDK, all shaders come in pre-compiled form, and there is no make rule to compile them. mplayer should be compilable without 500 MB of garbage. The main problem is that compiling shaders within an application seems to require d3dx9_*.dll, which isn't installed by default. Add an option ("disable-texture-align") that allows making the video textures exactly the same size as the source video. The code used to align the OSD texture size on 16 for unknown reasons, but since this was perhaps a good reason, this behavior is kept for video textures as well. (There is a chance that the alignment improves performance and stability with some drivers.) Passing this option disables this behavior. It is useful for reducing texture filtering artifacts at the bottom/right borders.
* vo_direct3d: reduce number of lock calls in OSD renderingwm42012-03-171-29/+21
| | | | | | The code locked the texture once for each OSD object that was rendered. But there doesn't seem to be any good reason to do that, so lock it only once during OSD rendering.
* vo_direct3d: use the same texture management for EOSD and OSDwm42012-03-171-152/+166
| | | | | | | | | | | | | | | | | | | The OSD code used a shadow texture on systems that don't report D3DDEVCAPS_TEXTURESYSTEMMEMORY. Do that for EOSD as well. Refactor the OSD texture management code to reduce code duplication. I have not the slightest clue about Direct3D9 texture management, so it seems like a good idea not to do something different for EOSD textures, even though the OSD code does exactly the same as far as texture handling goes. It's also worth noting that D3DDEVCAPS_TEXTURESYSTEMMEMORY doesn't seem to be supported by most real systems [1], and maintaining a shadow copy in system memory in order to update textures is required. The previous EOSD texture code may or may not have worked on some or all real systems, I can't really tell by reading the MSDN documentation only. [1] http://www.kludx.com/capability.php?capability=17
* vo_direct3d: make VO re-config faster by not recreating the whole D3D statewm42012-03-171-36/+38
| | | | | | | | | | | The D3D state (the IDirect3DDevice9 and all textures and buffers) were released and recreated in the config() function. This is completely unnecessary. Instead explicitly handle changes. The video surface is only reallocated if the video format or the video size changes. The OSD texture is only reallocated if the window size is increased. The EOSD texture is not released. Since the resize code is reused to deal with reconfig changes, some of these improvements (and possible bugs) apply to normal window resizing as well.
* vo_direct3d: don't framestep when paused and OSD is updatedwm42012-03-171-4/+23
| | | | | | | | | | The required feature for this, VOCTRL_REDRAW_OSD, was unimplemented for unknown reasons. It is trivial to add. There is still a weird issue when switching the fullscreen state while paused. I have no idea why this happens. The contents of the video should survive the window reconfiguration (at least we don't free it), and we explicitly redraw the screen after fullscreen.
* vo_direct3d: add EOSD supportwm42012-03-171-36/+335
| | | | | This allows rendering subtitles in display resolution. It also makes inserting the vf_ass video filter unnecessary.
* vo_direct3d: minor cleanupwm42012-03-171-10/+23
| | | | | | The code assumed the last format passed to query_format will be the one that is used on playback. This is probably true and thus didn't cause any bugs, but make query_format side effect free just like the other VOs.
* cleanup: vo_direct3d: Mark a function staticdiego2011-07-061-2/+3
| | | | | | | This fixes the warning: libvo/vo_direct3d.c:984:6: warning: no previous prototype for 'vo_draw_alpha_l8a8' git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@33499 b3059339-0415-0410-9bf9-f77b7e298cf2
* sub/OSD: move some related files to sub/Uoti Urpala2011-01-261-2/+2
|
* Merge svn changes up to r30195Uoti Urpala2010-01-081-7/+30
|\
| * Avoid memleaks when vo_direct3d initialization fails.reimar2010-01-031-8/+14
| | | | | | | | git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30191 b3059339-0415-0410-9bf9-f77b7e298cf2
| * Modify -vo direct3d so we do not have to link against d3d9.dll, it mightreimar2010-01-031-2/+19
| | | | | | | | | | | | | | | | not be available on some rare systems. Based on patch used for builds by Gianluigi Tiesi [sherpya netfarm it] git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@30190 b3059339-0415-0410-9bf9-f77b7e298cf2
* | Remove the internal GUIAnton Khirnov2009-07-071-2/+0
| | | | | | | | | | | | | | | | | | The GUI is badly designed and too closely coupled to the internal details of other code. The GUI code is in bad shape and unmaintained for years. There is no indication that anyone would maintain it in the future either. Even if someone did volunteer to implement a better integrated GUI having the current code in the tree probably wouldn't help much. So get rid of it.
* | Merge svn changes up to r28641Uoti Urpala2009-02-181-2/+8
|\| | | | | | | | | | | | | | | Convert vo_x11_border (used in vo_gl/gl2 though the vo_gl_border macro) to use a wrapper macro in old-style VOs which do not provide a VO object argument. Before this function had an explicit global_vo argument in vo_gl/gl2. New vo_vdpau uses it too so use the same mechanism as most other functions.
| * Extend calc_src_dst_rects to also calculate the border values needed forreimar2009-02-171-2/+8
| | | | | | | | | | | | | | correctly placed dvdnav highlights, and fix direct3d and vdpau accordingly. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28633 b3059339-0415-0410-9bf9-f77b7e298cf2
* | Merge svn changes up to r28549Uoti Urpala2009-02-131-41/+12
|\|
| * Add a calc_src_dst_rects that calculates from window size, panscan etc.reimar2009-02-121-41/+12
| | | | | | | | | | | | | | | | | | which part of the video source must be scaled onto which part of the window. Direct3D and (future) VDPAU need this, for XvMC it makes it easier to add cropping support and Xv is changed to keep the diff to XvMC small. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28546 b3059339-0415-0410-9bf9-f77b7e298cf2
* | Merge svn changes up to r28537Uoti Urpala2009-02-121-44/+44
|\|
| * Avoid message spam during video adapter uncooperative state.gogothebee2009-02-051-1/+1
| | | | | | | | git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28469 b3059339-0415-0410-9bf9-f77b7e298cf2
| * Unify info/error messages to a common style:gogothebee2009-02-051-43/+43
| | | | | | | | | | | | | | <vo_direct3d> in the beginning, "." at the end. Shorter/more descriptive sentences. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28468 b3059339-0415-0410-9bf9-f77b7e298cf2
* | Merge svn changes up to r28461Uoti Urpala2009-02-041-18/+28
|\|
| * Add checks that a D3D device is available before attempting rendering.reimar2009-02-031-1/+16
| | | | | | | | | | | | | | | | | | We may have lost the device e.g. because it became uncooperative e.g. when using remote desktop or Vista's UAC is activated. Patch by Georgi Petrov [gogothebee gmail com] git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28457 b3059339-0415-0410-9bf9-f77b7e298cf2
| * Remove the Present call after adapter reinitialization, it can not work anywayreimar2009-02-031-4/+0
| | | | | | | | | | | | | | since no video frame is uploaded to the new context yet. git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28456 b3059339-0415-0410-9bf9-f77b7e298cf2
| * Cosmetics: remove empty line, improve some messages.reimar2009-02-031-5/+3
| | | | | | | | git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28454 b3059339-0415-0410-9bf9-f77b7e298cf2
| * Whitespace/comment typo cosmetics.reimar2009-02-031-5/+5
| | | | | | | |