[webkit-dev] Stricter type checking in downcast<>()
Hi,
I have recently landed stricter type checking in downcast<>() [1]. It is
stricter because the check is now happening in release / production builds on
some platforms (ARM-based).
My objective is to enable to check in release on all platforms in the near
future (still a small performance hit on remaining platforms at the moment).
Because of this, it is now recommended to use dynamicDowncast<>() instead of
is<>() + downcast<>(), to avoid duplicating the type check.
dynamicDowncast<>() is also less error-prone and often results in more concise
code.
If you have a case where performance matters and you’re confident a type check
is not required, you may rely on uncheckedDowncast<>().
uncheckedDowncast<>() behaves the same way downcast<>() used to before my
change (type check on debug builds only).
One such example I’ve seen in our codebase is when using a switch statement
based on the type:
```
switch (node.nodeType()) {
case Node::DOCUMENT_TYPE_NODE:
uncheckedDowncast(node)->foo();
```
Please let me know if you have any concerns / questions.
Cheers,
Chris Dumez.
[1] https://commits.webkit.org/272296@main
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Patch WebKit to support custom Audio I/O handlers
Dear Everyone! Currently, we are working on a project that aims to extend Selenium's functionality in regard to the Audio Input and Output, which Selenium currently does not support. The goal is to be able to provide custom audio input/output to an internal website, which we want to test automatically. For this, we are currently evaluating a rather complex approach involving using special Linux VMs and PulseAudio, thus rerouting the audio through the PulseAudio server. This approach is, of course, rather unsatisfying and error prone. Which is why we are thinking about forking WebKit and implementing a custom audio backend relaying the audio input and the audio output of the website to a custom handler. Which is why I want to ask: * I am a novice in the WebKit project, how would you suggest starting this task? * If we really were to go this route, would you be interested in an upstream patch or would you prefer a fork instead? * (off-topic) Are there any different approaches other than the two suggested above? Yours faithfully, Alexander ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Patch WebKit to support custom Audio I/O handlers
Dear Everyone! Currently, we are working on a project that aims to extend Selenium's functionality in regard to the Audio Input and Output, which Selenium currently does not support. The goal is to be able to provide custom audio input/output to an internal website, which we want to test automatically. For this, we are currently evaluating a rather complex approach involving using special Linux VMs and PulseAudio, thus rerouting the audio through the PulseAudio server. This approach is, of course, rather unsatisfying and error prone. Which is why we are thinking about forking WebKit and implementing a custom audio backend relaying the audio input and the audio output of the website to a custom handler. Which is why I want to ask: * I am a novice in the WebKit project, how would you suggest starting this task? * If we really were to go this route, would you be interested in an upstream patch or would you prefer a fork instead? * (off-topic) Are there any different approaches other than the two suggested above? Yours faithfully, Alexander ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
