## Link to GitHub Issue or related Pull Request, if one exists #0 ## Description of change Significantly speeds up API screen capture and D3D9 screenshots saving. Two reasons for doing this: 1. We now have a 4K game (GITADORA) and existing capture code was taking multiple seconds. 2. Renewed user interest on streaming as we have a couple more companion apps in active development. **API screen capture (streaming), 1280x720:** 14.3ms -> 6.3ms per frame. Back buffer copies go to pooled `D3DPOOL_SYSTEMMEM` surfaces via `GetRenderTargetData` instead of allocating a lockable render target every frame, and TooJpeg is replaced with libjpeg-turbo (encode 9.8ms -> 3.0ms). MSAA remains unsupported **Screenshots for GITADORA arena model, across 4 screens with one of them 4K**: 4068ms -> 124ms. `D3DXSaveSurfaceToFileA` is replaced with fpng (encode 4043ms -> 76ms) and the screens encode in parallel. Dropping D3DX also removes the `d3dx9_43.dll` ... `d3dx9_24.dll` probing loop, so screenshots no longer fail outright on machines with no D3DX9 runtime installed. Screenshot surfaces are read on the present thread, so no D3D call reaches another thread for screenshots. This fixes a hang in DDR X2 introduced earlier in the branch: its device has no internal locking, and reading the surface on a pool thread while the present thread sat inside `GetRenderTargetData` left the game's own render thread deadlocked. ## Testing - **GITADORA** (arena model, D3D9Ex, 4K main plus three subscreens, windowed) with `-screenshotsub`: three sets of four screenshots, images verified correct. Completion order differs between sets, so the screens really are encoding in parallel. - **LovePlus** (KLP, plain D3D9, 768x1360): covers the inline path used by games whose image processing must not leave the present thread. - **API screen capture** through a companion app: live video correct throughout. - **Print Screen** bound as the screenshot key: the clipboard copy succeeded on every shot. - Quitting the game after capturing leaves no `IDirect3DDevice9` reference count warning, so the pooled readback surfaces are released along with the device.
170 lines
5.5 KiB
C
170 lines
5.5 KiB
C
/*
|
|
* jfdctflt.c
|
|
*
|
|
* Copyright (C) 1994-1996, Thomas G. Lane.
|
|
* This file is part of the Independent JPEG Group's software.
|
|
* For conditions of distribution and use, see the accompanying README.ijg
|
|
* file.
|
|
*
|
|
* This file contains a floating-point implementation of the
|
|
* forward DCT (Discrete Cosine Transform).
|
|
*
|
|
* This implementation should be more accurate than either of the integer
|
|
* DCT implementations. However, it may not give the same results on all
|
|
* machines because of differences in roundoff behavior. Speed will depend
|
|
* on the hardware's floating point capacity.
|
|
*
|
|
* A 2-D DCT can be done by 1-D DCT on each row followed by 1-D DCT
|
|
* on each column. Direct algorithms are also available, but they are
|
|
* much more complex and seem not to be any faster when reduced to code.
|
|
*
|
|
* This implementation is based on Arai, Agui, and Nakajima's algorithm for
|
|
* scaled DCT. Their original paper (Trans. IEICE E-71(11):1095) is in
|
|
* Japanese, but the algorithm is described in the Pennebaker & Mitchell
|
|
* JPEG textbook (see REFERENCES section in file README.ijg). The following
|
|
* code is based directly on figure 4-8 in P&M.
|
|
* While an 8-point DCT cannot be done in less than 11 multiplies, it is
|
|
* possible to arrange the computation so that many of the multiplies are
|
|
* simple scalings of the final outputs. These multiplies can then be
|
|
* folded into the multiplications or divisions by the JPEG quantization
|
|
* table entries. The AA&N method leaves only 5 multiplies and 29 adds
|
|
* to be done in the DCT itself.
|
|
* The primary disadvantage of this method is that with a fixed-point
|
|
* implementation, accuracy is lost due to imprecise representation of the
|
|
* scaled quantization values. However, that problem does not arise if
|
|
* we use floating point arithmetic.
|
|
*/
|
|
|
|
#define JPEG_INTERNALS
|
|
#include "jinclude.h"
|
|
#include "jpeglib.h"
|
|
#include "jdct.h" /* Private declarations for DCT subsystem */
|
|
|
|
#ifdef DCT_FLOAT_SUPPORTED
|
|
|
|
|
|
/*
|
|
* This module is specialized to the case DCTSIZE = 8.
|
|
*/
|
|
|
|
#if DCTSIZE != 8
|
|
Sorry, this code only copes with 8x8 DCTs. /* deliberate syntax err */
|
|
#endif
|
|
|
|
|
|
/*
|
|
* Perform the forward DCT on one block of samples.
|
|
*/
|
|
|
|
GLOBAL(void)
|
|
jpeg_fdct_float(FAST_FLOAT *data)
|
|
{
|
|
FAST_FLOAT tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7;
|
|
FAST_FLOAT tmp10, tmp11, tmp12, tmp13;
|
|
FAST_FLOAT z1, z2, z3, z4, z5, z11, z13;
|
|
FAST_FLOAT *dataptr;
|
|
int ctr;
|
|
|
|
/* Pass 1: process rows. */
|
|
|
|
dataptr = data;
|
|
for (ctr = DCTSIZE - 1; ctr >= 0; ctr--) {
|
|
tmp0 = dataptr[0] + dataptr[7];
|
|
tmp7 = dataptr[0] - dataptr[7];
|
|
tmp1 = dataptr[1] + dataptr[6];
|
|
tmp6 = dataptr[1] - dataptr[6];
|
|
tmp2 = dataptr[2] + dataptr[5];
|
|
tmp5 = dataptr[2] - dataptr[5];
|
|
tmp3 = dataptr[3] + dataptr[4];
|
|
tmp4 = dataptr[3] - dataptr[4];
|
|
|
|
/* Even part */
|
|
|
|
tmp10 = tmp0 + tmp3; /* phase 2 */
|
|
tmp13 = tmp0 - tmp3;
|
|
tmp11 = tmp1 + tmp2;
|
|
tmp12 = tmp1 - tmp2;
|
|
|
|
dataptr[0] = tmp10 + tmp11; /* phase 3 */
|
|
dataptr[4] = tmp10 - tmp11;
|
|
|
|
z1 = (tmp12 + tmp13) * ((FAST_FLOAT)0.707106781); /* c4 */
|
|
dataptr[2] = tmp13 + z1; /* phase 5 */
|
|
dataptr[6] = tmp13 - z1;
|
|
|
|
/* Odd part */
|
|
|
|
tmp10 = tmp4 + tmp5; /* phase 2 */
|
|
tmp11 = tmp5 + tmp6;
|
|
tmp12 = tmp6 + tmp7;
|
|
|
|
/* The rotator is modified from fig 4-8 to avoid extra negations. */
|
|
z5 = (tmp10 - tmp12) * ((FAST_FLOAT)0.382683433); /* c6 */
|
|
z2 = ((FAST_FLOAT)0.541196100) * tmp10 + z5; /* c2-c6 */
|
|
z4 = ((FAST_FLOAT)1.306562965) * tmp12 + z5; /* c2+c6 */
|
|
z3 = tmp11 * ((FAST_FLOAT)0.707106781); /* c4 */
|
|
|
|
z11 = tmp7 + z3; /* phase 5 */
|
|
z13 = tmp7 - z3;
|
|
|
|
dataptr[5] = z13 + z2; /* phase 6 */
|
|
dataptr[3] = z13 - z2;
|
|
dataptr[1] = z11 + z4;
|
|
dataptr[7] = z11 - z4;
|
|
|
|
dataptr += DCTSIZE; /* advance pointer to next row */
|
|
}
|
|
|
|
/* Pass 2: process columns. */
|
|
|
|
dataptr = data;
|
|
for (ctr = DCTSIZE - 1; ctr >= 0; ctr--) {
|
|
tmp0 = dataptr[DCTSIZE * 0] + dataptr[DCTSIZE * 7];
|
|
tmp7 = dataptr[DCTSIZE * 0] - dataptr[DCTSIZE * 7];
|
|
tmp1 = dataptr[DCTSIZE * 1] + dataptr[DCTSIZE * 6];
|
|
tmp6 = dataptr[DCTSIZE * 1] - dataptr[DCTSIZE * 6];
|
|
tmp2 = dataptr[DCTSIZE * 2] + dataptr[DCTSIZE * 5];
|
|
tmp5 = dataptr[DCTSIZE * 2] - dataptr[DCTSIZE * 5];
|
|
tmp3 = dataptr[DCTSIZE * 3] + dataptr[DCTSIZE * 4];
|
|
tmp4 = dataptr[DCTSIZE * 3] - dataptr[DCTSIZE * 4];
|
|
|
|
/* Even part */
|
|
|
|
tmp10 = tmp0 + tmp3; /* phase 2 */
|
|
tmp13 = tmp0 - tmp3;
|
|
tmp11 = tmp1 + tmp2;
|
|
tmp12 = tmp1 - tmp2;
|
|
|
|
dataptr[DCTSIZE * 0] = tmp10 + tmp11; /* phase 3 */
|
|
dataptr[DCTSIZE * 4] = tmp10 - tmp11;
|
|
|
|
z1 = (tmp12 + tmp13) * ((FAST_FLOAT)0.707106781); /* c4 */
|
|
dataptr[DCTSIZE * 2] = tmp13 + z1; /* phase 5 */
|
|
dataptr[DCTSIZE * 6] = tmp13 - z1;
|
|
|
|
/* Odd part */
|
|
|
|
tmp10 = tmp4 + tmp5; /* phase 2 */
|
|
tmp11 = tmp5 + tmp6;
|
|
tmp12 = tmp6 + tmp7;
|
|
|
|
/* The rotator is modified from fig 4-8 to avoid extra negations. */
|
|
z5 = (tmp10 - tmp12) * ((FAST_FLOAT)0.382683433); /* c6 */
|
|
z2 = ((FAST_FLOAT)0.541196100) * tmp10 + z5; /* c2-c6 */
|
|
z4 = ((FAST_FLOAT)1.306562965) * tmp12 + z5; /* c2+c6 */
|
|
z3 = tmp11 * ((FAST_FLOAT)0.707106781); /* c4 */
|
|
|
|
z11 = tmp7 + z3; /* phase 5 */
|
|
z13 = tmp7 - z3;
|
|
|
|
dataptr[DCTSIZE * 5] = z13 + z2; /* phase 6 */
|
|
dataptr[DCTSIZE * 3] = z13 - z2;
|
|
dataptr[DCTSIZE * 1] = z11 + z4;
|
|
dataptr[DCTSIZE * 7] = z11 - z4;
|
|
|
|
dataptr++; /* advance pointer to next column */
|
|
}
|
|
}
|
|
|
|
#endif /* DCT_FLOAT_SUPPORTED */
|