Android/scrcpy
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity
scrcpy/app/src/screen.h

122 lines
3.3 KiB
C
Raw Normal View History

Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
#ifndef SCREEN_H
#define SCREEN_H
Define feature test macros in common.h This enables necessary functions once for all. As a consequence, define common.h before any other header.
2021-01-09 02:24:51 +08:00
#include "common.h"
Replace SDL types by C99 standard types Scrcpy is a C11 project. Use the C99 standard types instead of the SDL-specific types: SDL_bool -> bool SintXX -> intXX_t UintXX -> uintXX_t
2019-03-03 06:52:22 +08:00
#include <stdbool.h>
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
#include <SDL2/SDL.h>
#include <libavformat/avformat.h>
Move common structs to coords.h The size, point and position structs were defined in common.h. Move them to coords.h so that common.h could be used for generic code to be included in all source files.
2021-01-09 02:15:29 +08:00
#include "coords.h"
Enable trilinear filtering for OpenGL Improve downscaling quality if mipmapping is available. Suggested-by: Giumo Clanjor (哆啦比猫/兰威举) <cjxgm2@gmail.com> Fixes #40 <https://github.com/Genymobile/scrcpy/issues/40> Ref: <https://github.com/Genymobile/scrcpy/issues/40#issuecomment-591917787>
2020-04-11 22:08:23 +08:00
#include "opengl.h"
Rename "frames" to "video_buffer" It better describes the purpose of the structure.
2019-03-02 22:16:55 +08:00
struct video_buffer;
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
struct screen {
Reference video buffer from screen This paves the way to handle EVENT_NEW_FRAME from screen.c, by allowing to call screen_update_frame() without an explicit video_buffer instance.
2021-02-16 01:28:41 +08:00
struct video_buffer *vb;
Move fps counter out of video buffer In order to make video buffer more generic, move out its specific responsibility to count the fps between the decoder and the renderer.
2021-02-20 03:56:09 +08:00
struct fps_counter *fps_counter;
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
SDL_Window *window;
SDL_Renderer *renderer;
SDL_Texture *texture;
Enable trilinear filtering for OpenGL Improve downscaling quality if mipmapping is available. Suggested-by: Giumo Clanjor (哆啦比猫/兰威举) <cjxgm2@gmail.com> Fixes #40 <https://github.com/Genymobile/scrcpy/issues/40> Ref: <https://github.com/Genymobile/scrcpy/issues/40#issuecomment-591917787>
2020-04-11 22:08:23 +08:00
struct sc_opengl gl;
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
struct size frame_size;
Store rotated content size This avoids to compute it every time from the frame size.
2020-04-08 20:11:23 +08:00
struct size content_size; // rotated frame_size
Simplify size changes in fullscreen or maximized If the content size changes (due to rotation for example) while the window is maximized or fullscreen, the resize must be applied once fullscreen and maximized are disabled. The previous strategy consisted in storing the windowed size, computing the target size on rotation, and applying it on window restoration. But tracking the windowed size (while ignoring the non-windowed size) was tricky, due to unspecified order of SDL events (e.g. size changes can be notified before "maximized" events), race conditions when reading window flags, different behaviors on different platforms... To simplify the whole resize management, store the old content size (the frame size, possibly rotated) when it changes while the window is maximized or fullscreen, so that the new optimal size can be computed on window restoration.
2020-05-11 09:11:13 +08:00
bool resize_pending; // resize requested while fullscreen or maximized
// The content size the last time the window was not maximized or
// fullscreen (meaningful only when resize_pending is true)
struct size windowed_content_size;
Add shortcuts to rotate display Add Ctrl+Left and Ctrl+Right shortcuts to rotate the display (the content of the scrcpy window). Contrary to --lock-video-orientation, the rotation has no impact on recording, and can be changed dynamically (and immediately). Fixes #218 <https://github.com/Genymobile/scrcpy/issues/218>
2020-04-08 05:03:23 +08:00
// client rotation: 0, 1, 2 or 3 (x90 degrees counterclockwise)
unsigned rotation;
Manually position and scale the content Position and scale the content "manually" instead of relying on the renderer "logical size". This avoids possible rounding differences between the computed window size and the content size, causing one row or column of black pixels on the bottom or on the right. This also avoids HiDPI scale issues, by computing the scaling manually. This will also enable to draw items at their expected size on the screen (unscaled). Fixes #15 <https://github.com/Genymobile/scrcpy/issues/15>
2020-04-18 00:44:24 +08:00
// rectangle of the content (excluding black borders)
struct SDL_Rect rect;
Replace SDL types by C99 standard types Scrcpy is a C11 project. Use the C99 standard types instead of the SDL-specific types: SDL_bool -> bool SintXX -> intXX_t UintXX -> uintXX_t
2019-03-03 06:52:22 +08:00
bool has_frame;
bool fullscreen;
Fix rotation while the window is maximized Keep the windowed window size to handle maximized window the same way as fullscreen window. Fixes <https://github.com/Genymobile/scrcpy/issues/750>
2019-11-12 04:26:35 +08:00
bool maximized;
Enable trilinear filtering for OpenGL Improve downscaling quality if mipmapping is available. Suggested-by: Giumo Clanjor (哆啦比猫/兰威举) <cjxgm2@gmail.com> Fixes #40 <https://github.com/Genymobile/scrcpy/issues/40> Ref: <https://github.com/Genymobile/scrcpy/issues/40#issuecomment-591917787>
2020-04-11 22:08:23 +08:00
bool mipmaps;
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
};
Group screen parameters into a struct The function screen_init_rendering had too many parameters.
2021-02-26 05:00:34 +08:00
struct screen_params {
const char *window_title;
struct size frame_size;
bool always_on_top;
int16_t window_x;
int16_t window_y;
uint16_t window_width; // accepts SC_WINDOW_POSITION_UNDEFINED
uint16_t window_height; // accepts SC_WINDOW_POSITION_UNDEFINED
bool window_borderless;
uint8_t rotation;
bool mipmaps;
};
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
// initialize default values
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-03 03:09:56 +08:00
void
Move fps counter out of video buffer In order to make video buffer more generic, move out its specific responsibility to count the fps between the decoder and the renderer.
2021-02-20 03:56:09 +08:00
screen_init(struct screen *screen, struct video_buffer *vb,
struct fps_counter *fps_counter);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
Improve startup time On startup, the client has to: 1. listen on a port 2. push and start the server to the device 3. wait for the server to connect (accept) 4. read device name and size 5. initialize SDL 6. initialize the window and renderer 7. show the window From the execution of the app_process command to start the server on the device, to the execution of the java main method, it takes ~800ms. As a consequence, step 3 also takes ~800ms on the client. Once complete, the client initializes SDL, which takes ~500ms. These two expensive actions are executed sequentially: HOST DEVICE listen on port | | push/start the server |----------------->|| app_process loads the jar accept the connection . ^ || . | || . | WASTE || . | OF || . | TIME || . | || . | || . v X execution of our java main connection accepted |<-----------------| connect to the host init SDL || | || ,----------------| send frames || |,---------------| || ||,--------------| || |||,-------------| || ||||,------------| init window/renderer | |||||,-----------| display frames |<++++++-----------| (many frames skipped) The rationale for step 3 occuring before step 5 is that initializing SDL replaces the SIGTERM handler to receive the event in the event loop, so pressing Ctrl+C during step 5 would not work (since it blocks the event loop). But this is not so important; let's parallelize the SDL initialization with the app_process execution (we'll just add a timeout to the connection): HOST DEVICE listen on port | | push/start the server |----------------->||app_process loads the jar init SDL || || || || || || || || || || || || accept the connection . || . X execution of our java main connection accepted |<-----------------| connect to the host init window/renderer | | display frames |<-----------------| send frames |<-----------------| In addition, show the window only once the first frame is available to avoid flickering (opening a black window for 100~200ms). Note: the window and renderer are initialized after the connection is accepted because they use the device information received from the device.
2018-02-09 20:50:54 +08:00
// initialize screen, create window, renderer and texture (window is hidden)
Replace SDL types by C99 standard types Scrcpy is a C11 project. Use the C99 standard types instead of the SDL-specific types: SDL_bool -> bool SintXX -> intXX_t UintXX -> uintXX_t
2019-03-03 06:52:22 +08:00
bool
Group screen parameters into a struct The function screen_init_rendering had too many parameters.
2021-02-26 05:00:34 +08:00
screen_init_rendering(struct screen *screen,
const struct screen_params *params);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
Improve startup time On startup, the client has to: 1. listen on a port 2. push and start the server to the device 3. wait for the server to connect (accept) 4. read device name and size 5. initialize SDL 6. initialize the window and renderer 7. show the window From the execution of the app_process command to start the server on the device, to the execution of the java main method, it takes ~800ms. As a consequence, step 3 also takes ~800ms on the client. Once complete, the client initializes SDL, which takes ~500ms. These two expensive actions are executed sequentially: HOST DEVICE listen on port | | push/start the server |----------------->|| app_process loads the jar accept the connection . ^ || . | || . | WASTE || . | OF || . | TIME || . | || . | || . v X execution of our java main connection accepted |<-----------------| connect to the host init SDL || | || ,----------------| send frames || |,---------------| || ||,--------------| || |||,-------------| || ||||,------------| init window/renderer | |||||,-----------| display frames |<++++++-----------| (many frames skipped) The rationale for step 3 occuring before step 5 is that initializing SDL replaces the SIGTERM handler to receive the event in the event loop, so pressing Ctrl+C during step 5 would not work (since it blocks the event loop). But this is not so important; let's parallelize the SDL initialization with the app_process execution (we'll just add a timeout to the connection): HOST DEVICE listen on port | | push/start the server |----------------->||app_process loads the jar init SDL || || || || || || || || || || || || accept the connection . || . X execution of our java main connection accepted |<-----------------| connect to the host init window/renderer | | display frames |<-----------------| send frames |<-----------------| In addition, show the window only once the first frame is available to avoid flickering (opening a black window for 100~200ms). Note: the window and renderer are initialized after the connection is accepted because they use the device information received from the device.
2018-02-09 20:50:54 +08:00
// show the window
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-03 03:09:56 +08:00
void
screen_show_window(struct screen *screen);
Improve startup time On startup, the client has to: 1. listen on a port 2. push and start the server to the device 3. wait for the server to connect (accept) 4. read device name and size 5. initialize SDL 6. initialize the window and renderer 7. show the window From the execution of the app_process command to start the server on the device, to the execution of the java main method, it takes ~800ms. As a consequence, step 3 also takes ~800ms on the client. Once complete, the client initializes SDL, which takes ~500ms. These two expensive actions are executed sequentially: HOST DEVICE listen on port | | push/start the server |----------------->|| app_process loads the jar accept the connection . ^ || . | || . | WASTE || . | OF || . | TIME || . | || . | || . v X execution of our java main connection accepted |<-----------------| connect to the host init SDL || | || ,----------------| send frames || |,---------------| || ||,--------------| || |||,-------------| || ||||,------------| init window/renderer | |||||,-----------| display frames |<++++++-----------| (many frames skipped) The rationale for step 3 occuring before step 5 is that initializing SDL replaces the SIGTERM handler to receive the event in the event loop, so pressing Ctrl+C during step 5 would not work (since it blocks the event loop). But this is not so important; let's parallelize the SDL initialization with the app_process execution (we'll just add a timeout to the connection): HOST DEVICE listen on port | | push/start the server |----------------->||app_process loads the jar init SDL || || || || || || || || || || || || accept the connection . || . X execution of our java main connection accepted |<-----------------| connect to the host init window/renderer | | display frames |<-----------------| send frames |<-----------------| In addition, show the window only once the first frame is available to avoid flickering (opening a black window for 100~200ms). Note: the window and renderer are initialized after the connection is accepted because they use the device information received from the device.
2018-02-09 20:50:54 +08:00
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
// destroy window, renderer and texture (if any)
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-03 03:09:56 +08:00
void
screen_destroy(struct screen *screen);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
// render the texture to the renderer
Manually position and scale the content Position and scale the content "manually" instead of relying on the renderer "logical size". This avoids possible rounding differences between the computed window size and the content size, causing one row or column of black pixels on the bottom or on the right. This also avoids HiDPI scale issues, by computing the scaling manually. This will also enable to draw items at their expected size on the screen (unscaled). Fixes #15 <https://github.com/Genymobile/scrcpy/issues/15>
2020-04-18 00:44:24 +08:00
//
// Set the update_content_rect flag if the window or content size may have
// changed, so that the content rectangle is recomputed
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-03 03:09:56 +08:00
void
Manually position and scale the content Position and scale the content "manually" instead of relying on the renderer "logical size". This avoids possible rounding differences between the computed window size and the content size, causing one row or column of black pixels on the bottom or on the right. This also avoids HiDPI scale issues, by computing the scaling manually. This will also enable to draw items at their expected size on the screen (unscaled). Fixes #15 <https://github.com/Genymobile/scrcpy/issues/15>
2020-04-18 00:44:24 +08:00
screen_render(struct screen *screen, bool update_content_rect);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
// switch the fullscreen mode
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-03 03:09:56 +08:00
void
screen_switch_fullscreen(struct screen *screen);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
// resize window to optimal size (remove black borders)
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-03 03:09:56 +08:00
void
screen_resize_to_fit(struct screen *screen);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
// resize window to 1:1 (pixel-perfect)
Update code style Limit source code to 80 chars, and declare functions return type and modifiers on a separate line. This allows to avoid very long lines, and all function names are aligned. (We do this on VLC, and I like it.)
2019-03-03 03:09:56 +08:00
void
screen_resize_to_pixel_perfect(struct screen *screen);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
Add shortcuts to rotate display Add Ctrl+Left and Ctrl+Right shortcuts to rotate the display (the content of the scrcpy window). Contrary to --lock-video-orientation, the rotation has no impact on recording, and can be changed dynamically (and immediately). Fixes #218 <https://github.com/Genymobile/scrcpy/issues/218>
2020-04-08 05:03:23 +08:00
// set the display rotation (0, 1, 2 or 3, x90 degrees counterclockwise)
void
screen_set_rotation(struct screen *screen, unsigned rotation);
Handle screen-related events from screen.c
2021-02-16 01:44:53 +08:00
// react to SDL events
bool
screen_handle_event(struct screen *screen, SDL_Event *event);
Handle window events from screen.c Only the screen knows what to do on window events. This paves the way to handle more window events.
2019-10-20 21:32:33 +08:00
Move rotation coordinates to screen Move the window-to-frame coordinates conversion from the input manager to the screen. This will allow to apply more screen-related transformations without impacting the input manager.
2020-04-18 00:43:29 +08:00
// convert point from window coordinates to frame coordinates
// x and y are expressed in pixels
struct point
Fix touch events HiDPI-scaling Touch events were HiDPI-scaled twice: - once because the position (provided as floats between 0 and 1) were converted in pixels using the drawable size (not the window size) - once due to screen_convert_to_frame_coords() One possible fix could be to compute the position in pixels from the window size instead, but this would unnecessarily round the event position to the nearest window coordinates (instead of drawable coordinates). Instead, expose two separate functions to convert to frame coordinates from either window or drawable coordinates. Fixes #1536 <https://github.com/Genymobile/scrcpy/issues/1536> Refs #15 <https://github.com/Genymobile/scrcpy/issues/15> Refs e40532a3761da8b3aef484f1d435ef5f50d94574
2020-06-25 14:54:40 +08:00
screen_convert_window_to_frame_coords(struct screen *screen,
int32_t x, int32_t y);
// convert point from drawable coordinates to frame coordinates
// x and y are expressed in pixels
struct point
screen_convert_drawable_to_frame_coords(struct screen *screen,
int32_t x, int32_t y);
Move rotation coordinates to screen Move the window-to-frame coordinates conversion from the input manager to the screen. This will allow to apply more screen-related transformations without impacting the input manager.
2020-04-18 00:43:29 +08:00
Manually position and scale the content Position and scale the content "manually" instead of relying on the renderer "logical size". This avoids possible rounding differences between the computed window size and the content size, causing one row or column of black pixels on the bottom or on the right. This also avoids HiDPI scale issues, by computing the scaling manually. This will also enable to draw items at their expected size on the screen (unscaled). Fixes #15 <https://github.com/Genymobile/scrcpy/issues/15>
2020-04-18 00:44:24 +08:00
// Convert coordinates from window to drawable.
// Events are expressed in window coordinates, but content is expressed in
// drawable coordinates. They are the same if HiDPI scaling is 1, but differ
// otherwise.
void
screen_hidpi_scale_coords(struct screen *screen, int32_t *x, int32_t *y);
Move screen-related code to screen.c The file scrcpy.c contains too many different things in addition to the main logic, so move the screen code to a separate file, screen.c.
2018-02-08 18:14:13 +08:00
#endif
Reference in a new issue Copy permalink