Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-03 06:41:00 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Painting/MediaPaintable.h

68 lines
3.2 KiB
C
Raw Normal View History

LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
/*
* Copyright (c) 2023, Tim Flynn <trflynn89@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <LibWeb/Forward.h>
LibWeb: Implement scrubbing of the media element timeline and volume This implements the ability to drag the timeline and volume buttons on UA-rendered media controls. The two behave a bit differently: Volume is updated as the user drags the volume button. This isn't a very expensive operation, so updating in real-time and hearing the volume change feels nice. The current time, on the other hand, is not committed until the user releases the mouse button. Performing a seek every time we get a mouse- move event is pretty laggy, especially for video. However, we still want to render updates on the timeline itself (so the position of the button and the timestamp update as you drag). To do so, we internally pause the media and override the timestamp provided to the layout node. In the future, we may be able to seek video periodically to provide some visual feedback. For example, we can seek after every N seconds of scrubbing, or when the user pauses scrubbing for a while.
2023-06-21 17:08:50 -04:00
#include <LibWeb/HTML/HTMLMediaElement.h>
LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
#include <LibWeb/Painting/PaintableBox.h>
LibWeb: Compute some media timeline rects/sizes before painting anything The idea here is to let us decide ahead of time what components to paint depending on the size available. We currently paint each component left- to-right, until we run out of room. This implicitly gives priority to the left-most components. We will soon paint volume controls on the right-side of the timeline. Subjectively, they should have a higher priority than, say, the timeline scrubbing bar (i.e. it's more important to be able to mute audio than to seek). By computing these components before painting, we can more easily allocate sections to the components in priority order, until the area remaining has been depleted.
2023-06-15 14:28:32 -04:00
#include <LibWeb/PixelUnits.h>
LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
namespace Web::Painting {
class MediaPaintable : public PaintableBox {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(MediaPaintable, PaintableBox);
LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
protected:
explicit MediaPaintable(Layout::ReplacedBox const&);
static Optional<DevicePixelPoint> mouse_position(PaintContext&, HTML::HTMLMediaElement const&);
LibWeb: Rename RecordingPainter to DisplayListRecorder Use more widely recognized name among browser engine developers.
2024-06-23 18:40:10 +02:00
static void fill_triangle(DisplayListRecorder& painter, Gfx::IntPoint location, Array<Gfx::IntPoint, 3> coordinates, Color color);
LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
void paint_media_controls(PaintContext&, HTML::HTMLMediaElement const&, DevicePixelRect media_rect, Optional<DevicePixelPoint> const& mouse_position) const;
private:
LibWeb: Compute some media timeline rects/sizes before painting anything The idea here is to let us decide ahead of time what components to paint depending on the size available. We currently paint each component left- to-right, until we run out of room. This implicitly gives priority to the left-most components. We will soon paint volume controls on the right-side of the timeline. Subjectively, they should have a higher priority than, say, the timeline scrubbing bar (i.e. it's more important to be able to mute audio than to seek). By computing these components before painting, we can more easily allocate sections to the components in priority order, until the area remaining has been depleted.
2023-06-15 14:28:32 -04:00
struct Components {
DevicePixelRect control_box_rect;
DevicePixelRect playback_button_rect;
DevicePixelRect timeline_rect;
String timestamp;
RefPtr<Gfx::Font> timestamp_font;
DevicePixelRect timestamp_rect;
LibWeb: Draw a speaker on media elements to toggle muting audio
2023-06-15 15:09:47 -04:00
DevicePixelRect speaker_button_rect;
DevicePixels speaker_button_size;
LibWeb: Draw a volume scrub bar on media elements to control volume
2023-06-15 15:46:37 -04:00
DevicePixelRect volume_rect;
LibWeb: Move the media volume slider 1:1 with the mouse cursor The volume control's slider is drawn in a rectangle shrunken by its slider handle's size, so the handle did not move 1:1 with the user's mouse movement. To fix this, it will now check for a mousedown in the volume control with a rectangle sized to fit any possible position of the handle, but the volume value result will be calculated based on the center of the handle instead. This allows it to move 1:1 with the mouse cursor. Co-authored-by: trflynn89 <trflynn89@serenityos.org>
2023-08-03 17:53:35 -05:00
DevicePixelRect volume_scrub_rect;
LibWeb: Draw a volume scrub bar on media elements to control volume
2023-06-15 15:46:37 -04:00
DevicePixels volume_button_size;
LibWeb: Compute some media timeline rects/sizes before painting anything The idea here is to let us decide ahead of time what components to paint depending on the size available. We currently paint each component left- to-right, until we run out of room. This implicitly gives priority to the left-most components. We will soon paint volume controls on the right-side of the timeline. Subjectively, they should have a higher priority than, say, the timeline scrubbing bar (i.e. it's more important to be able to mute audio than to seek). By computing these components before painting, we can more easily allocate sections to the components in priority order, until the area remaining has been depleted.
2023-06-15 14:28:32 -04:00
};
LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
virtual bool wants_mouse_events() const override { return true; }
LibWeb: Implement scrubbing of the media element timeline and volume This implements the ability to drag the timeline and volume buttons on UA-rendered media controls. The two behave a bit differently: Volume is updated as the user drags the volume button. This isn't a very expensive operation, so updating in real-time and hearing the volume change feels nice. The current time, on the other hand, is not committed until the user releases the mouse button. Performing a seek every time we get a mouse- move event is pretty laggy, especially for video. However, we still want to render updates on the timeline itself (so the position of the button and the timestamp update as you drag). To do so, we internally pause the media and override the timestamp provided to the layout node. In the future, we may be able to seek video periodically to provide some visual feedback. For example, we can seek after every N seconds of scrubbing, or when the user pauses scrubbing for a while.
2023-06-21 17:08:50 -04:00
virtual DispatchEventOfSameName handle_mousedown(Badge<EventHandler>, CSSPixelPoint, unsigned button, unsigned modifiers) override;
LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
virtual DispatchEventOfSameName handle_mouseup(Badge<EventHandler>, CSSPixelPoint, unsigned button, unsigned modifiers) override;
virtual DispatchEventOfSameName handle_mousemove(Badge<EventHandler>, CSSPixelPoint, unsigned buttons, unsigned modifiers) override;
LibWeb: Compute some media timeline rects/sizes before painting anything The idea here is to let us decide ahead of time what components to paint depending on the size available. We currently paint each component left- to-right, until we run out of room. This implicitly gives priority to the left-most components. We will soon paint volume controls on the right-side of the timeline. Subjectively, they should have a higher priority than, say, the timeline scrubbing bar (i.e. it's more important to be able to mute audio than to seek). By computing these components before painting, we can more easily allocate sections to the components in priority order, until the area remaining has been depleted.
2023-06-15 14:28:32 -04:00
Components compute_control_bar_components(PaintContext&, HTML::HTMLMediaElement const&, DevicePixelRect media_rect) const;
static void paint_control_bar_playback_button(PaintContext&, HTML::HTMLMediaElement const&, Components const&, Optional<DevicePixelPoint> const& mouse_position);
LibWeb: Paint the media timeline above the other media controls It's a little bit of a battle to fit all of the media controls in the available width of the media element. We currently cram everything on one horizontal line. We've made adjustments to be able to fit it all, but the controls (in particular the media timeline) are rather squished. This paints the timeline above the other media controls now. This provides much more granular control over the playback position when scrubbing, and makes it much more likely for the timeline to render at all.
2023-06-22 13:25:17 -04:00
static void paint_control_bar_timeline(PaintContext&, HTML::HTMLMediaElement const&, Components const&);
LibWeb: Compute some media timeline rects/sizes before painting anything The idea here is to let us decide ahead of time what components to paint depending on the size available. We currently paint each component left- to-right, until we run out of room. This implicitly gives priority to the left-most components. We will soon paint volume controls on the right-side of the timeline. Subjectively, they should have a higher priority than, say, the timeline scrubbing bar (i.e. it's more important to be able to mute audio than to seek). By computing these components before painting, we can more easily allocate sections to the components in priority order, until the area remaining has been depleted.
2023-06-15 14:28:32 -04:00
static void paint_control_bar_timestamp(PaintContext&, Components const&);
LibWeb: Draw a speaker on media elements to toggle muting audio
2023-06-15 15:09:47 -04:00
static void paint_control_bar_speaker(PaintContext&, HTML::HTMLMediaElement const&, Components const& components, Optional<DevicePixelPoint> const& mouse_position);
LibWeb: Draw a volume scrub bar on media elements to control volume
2023-06-15 15:46:37 -04:00
static void paint_control_bar_volume(PaintContext&, HTML::HTMLMediaElement const&, Components const&, Optional<DevicePixelPoint> const& mouse_position);
LibWeb: Implement scrubbing of the media element timeline and volume This implements the ability to drag the timeline and volume buttons on UA-rendered media controls. The two behave a bit differently: Volume is updated as the user drags the volume button. This isn't a very expensive operation, so updating in real-time and hearing the volume change feels nice. The current time, on the other hand, is not committed until the user releases the mouse button. Performing a seek every time we get a mouse- move event is pretty laggy, especially for video. However, we still want to render updates on the timeline itself (so the position of the button and the timestamp update as you drag). To do so, we internally pause the media and override the timestamp provided to the layout node. In the future, we may be able to seek video periodically to provide some visual feedback. For example, we can seek after every N seconds of scrubbing, or when the user pauses scrubbing for a while.
2023-06-21 17:08:50 -04:00
enum class Temporary {
Yes,
No,
};
static void set_current_time(HTML::HTMLMediaElement& media_element, CSSPixelRect timeline_rect, CSSPixelPoint mouse_position, Temporary);
static void set_volume(HTML::HTMLMediaElement& media_element, CSSPixelRect volume_rect, CSSPixelPoint mouse_position);
static bool rect_is_hovered(HTML::HTMLMediaElement const& media_element, Optional<DevicePixelRect> const& rect, Optional<DevicePixelPoint> const& mouse_position, Optional<HTML::HTMLMediaElement::MouseTrackingComponent> const& allowed_mouse_tracking_component = {});
LibWeb: Extract media element timeline painting to a base class This moves the painting of the media timeout out of VideoPaintable into a base MediaPaintable. This is to allow re-using the same timeline logic and controls for audio elements.
2023-06-12 08:21:35 -04:00
};
}
Reference in a new issue Copy permalink