Tunning eyebuffersize & performance level on PFDM MR device

[EasonZxp]

Since the PFDM MR device uses two 4K screens, and the recommended eye buffer size is 2880x2664, using this recommended eyeBuffer size would cause severe performance issues, so a ratio is added to reduce the rendering resolution

Closes #1805

[EasonZxp]

@svillar

I added a ratio to adjust the eyebuffer, and also set the perf setting level to high on PFDM MR devices.

This allows us to achieve 90 FPS in scenes with high rendering pressure, such as when multiple tabs are open.

Pls help to review.

[svillar]

I understand the rationale of the change but the problem seems to be more on the side of the runtime that recommends a resolution that is perhaps excessive for the computing power of the machine. What I mean is that recommendedImageRect* should have sensible values and should not require any adjustment.

That's why I think you should better add the code under #ifdef PDFM because the current code is fundamentally correct, and those specifics should be handled as what they are, i.e., exceptions to the norm.

[EasonZxp]

I understand the rationale of the change but the problem seems to be more on the side of the runtime that recommends a resolution that is perhaps excessive for the computing power of the machine. What I mean is that recommendedImageRect* should have sensible values and should not require any adjustment.

That's why I think you should better add the code under #ifdef PDFM because the current code is fundamentally correct, and those specifics should be handled as what they are, i.e., exceptions to the norm.

Thank you for the clarification. From the device manufacturer's perspective, they are leveraging 4K screens where a higher EyeBuffer resolution is recommended to fully utilize the display capabilities. While the suggested EyeBuffer size may work smoothly for certain applications, performance issues could arise in heavy-load scenarios. This makes it challenging to define a one-size-fits-all recommendation value across all use cases.

Regarding the code adjustment, yes – my modification already includes a check for PDFM.

Are you proposing to enforce stricter control through macro definitions (i.e., #ifdef PDFM)? If so, I can submit a modification again.

Thanks

[svillar]

I understand the rationale of the change but the problem seems to be more on the side of the runtime that recommends a resolution that is perhaps excessive for the computing power of the machine. What I mean is that recommendedImageRect* should have sensible values and should not require any adjustment.
That's why I think you should better add the code under #ifdef PDFM because the current code is fundamentally correct, and those specifics should be handled as what they are, i.e., exceptions to the norm.

Thank you for the clarification. From the device manufacturer's perspective, they are leveraging 4K screens where a higher EyeBuffer resolution is recommended to fully utilize the display capabilities. While the suggested EyeBuffer size may work smoothly for certain applications, performance issues could arise in heavy-load scenarios. This makes it challenging to define a one-size-fits-all recommendation value across all use cases.

Regarding the code adjustment, yes – my modification already includes a check for PDFM.

Are you proposing to enforce stricter control through macro definitions (i.e., #ifdef PDFM)? If so, I can submit a modification again.

Thanks

Yes, exactly. I know you added a device type check. What I mean is that that should not be normal code flow, the code should not require any adjustment, so if anything is needed then we should do it guarded by an ifdef for the specific flavour of PDFM indeed.

[svillar]

Hmm, this will likely increase the battery consumption and quickly heat up the device. Is it really needed for the rendering of the browser window and the rest of the UI? Note that for XR and fullscreen videos this will be set anyway.

[svillar]

@EasonZxp could you comment on what I wrote above please?