-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: 增加编译耗时的统计 #657
base: main
Are you sure you want to change the base?
feat: 增加编译耗时的统计 #657
Conversation
WalkthroughThe changes introduce performance measurement metrics for shader compilation in the Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Outside diff range and nitpick comments (6)
web-packages/demo/html/single.html (1)
10-18
: LGTM! Consider addingaria-hidden
for accessibility.The CSS changes for the
.container
class create a smooth animation effect for showing/hiding the container. This is a good implementation for modal or overlay elements.Consider adding an
aria-hidden="true"
attribute to the container element when it's not visible to improve accessibility for screen readers. You can toggle this attribute along with theactive
class in your JavaScript.web-packages/demo/src/single.ts (3)
3-7
: Improve code clarity and documentation for JSON sourcesWhile the change in JSON source is noted, the presence of multiple commented-out URLs could lead to confusion. Consider the following improvements:
- Add clear comments explaining what each URL represents (e.g., "Large particle scene", "Taji scene").
- Consider moving these URLs to a configuration file or constants for better maintainability.
- Remove outdated or unnecessary commented code to reduce clutter.
Here's a suggested improvement:
// Configuration for different scenes const SCENE_URLS = { LARGE_PARTICLE: 'https://mdn.alipayobjects.com/mars/afts/file/A*aCeuQ5RQZj4AAAAAAAAAAAAADlB4AQ', TAJI: 'https://mdn.alipayobjects.com/mars/afts/file/A*uU2JRIjcLIcAAAAAAAAAAAAADlB4AQ', }; // Current scene to load const json = SCENE_URLS.TAJI;
10-19
: Approve changes to Player creation and scene loadingThe modifications improve user control by moving the Player creation and scene loading into a button click event. This is a good practice for better user experience.
Consider adding a loading indicator or disabling the button while the scene is loading to prevent multiple clicks. For example:
document.getElementById('J-button')!.addEventListener('click', async (event) => { const button = event.target as HTMLButtonElement; button.disabled = true; try { // ... (existing code) } catch (e) { console.error('biz', e); } finally { button.disabled = false; } });Also, you might want to consider exposing the 'renderFramework' option as a user-configurable setting if it's relevant for different use cases.
21-27
: Approve addition of statistics display with suggestions for improvementThe addition of composition statistics display is a valuable feature. However, there are a few points to consider:
The use of
@ts-expect-error
suggests a type issue. It's better to properly type thecomposition.statistic
object to avoid suppressing TypeScript errors.The code assumes the existence of an element with id 'J-statistic'. It would be safer to check for its existence before attempting to append child elements.
Consider refactoring the code as follows:
interface Statistic { [key: string]: number | string; } // Assuming composition.statistic is of type Statistic const statisticElement = document.getElementById('J-statistic'); if (statisticElement) { Object.entries(composition.statistic as Statistic).forEach(([key, value]) => { const listItem = document.createElement('li'); listItem.textContent = `${key}: ${value}`; statisticElement.appendChild(listItem); }); }This refactoring properly types the statistic object, checks for the existence of the 'J-statistic' element, and uses
textContent
instead ofinnerHTML
for better security.packages/effects-core/src/composition.ts (1)
27-34
: LGTM! Consider reordering properties for better readability.The addition of
compileTime
and the explanatory comments enhance the interface's clarity and provide more detailed performance metrics. This is a good improvement.Consider reordering the properties to group related metrics together, which could improve readability:
export interface CompositionStatistic { loadStart: number, loadTime: number, compileTime: number, firstFrameTime: number, }This order groups loading-related metrics together and places compilation time before the first frame time, which seems to be a more logical sequence.
packages/effects/src/player.ts (1)
403-409
: LGTM: Implemented compilation time measurement and logging.These changes successfully implement the compilation time measurement and add it to the composition statistics. The additional log statements provide valuable information for performance monitoring.
Consider using template literals for the log messages to improve readability:
- logger.info(`First frame: [${composition.name}]${firstFrameTime.toFixed(4)}ms.`); - logger.info(`Shader compile: [${composition.name}]${compileTime.toFixed(4)}ms.`); + logger.info(`First frame: [${composition.name}] ${firstFrameTime.toFixed(4)}ms`); + logger.info(`Shader compile: [${composition.name}] ${compileTime.toFixed(4)}ms`);
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (5)
- packages/effects-core/src/asset-manager.ts (1 hunks)
- packages/effects-core/src/composition.ts (2 hunks)
- packages/effects/src/player.ts (2 hunks)
- web-packages/demo/html/single.html (1 hunks)
- web-packages/demo/src/single.ts (1 hunks)
Additional comments not posted (6)
web-packages/demo/html/single.html (2)
21-25
: LGTM! Good implementation of the active state.The
.container.active
class correctly implements the visible state of the container, working well with the transition effect defined in the.container
class.
29-32
: LGTM! Please clarify the purpose of the statistics list.The addition of the button for user interaction is clear and well-implemented.
Could you please clarify the purpose of the
<ul id="J-statistic"></ul>
element? It's not immediately clear how this will be used. Consider adding a comment in the HTML or providing more context in the PR description.To help understand the usage, let's check for any JavaScript code that might be interacting with this element:
packages/effects-core/src/asset-manager.ts (1)
175-176
: LGTM! Potential performance improvement.The changes in the
Promise.all
call look good and may lead to improved performance:
- Simplification of the precompile hook naming by removing the
asyncShaderCompile
condition.- Moving
processFontURL
into thePromise.all
allows for concurrent processing of fonts with other assets.These changes maintain the core functionality while potentially speeding up the asset loading process by parallelizing operations.
packages/effects-core/src/composition.ts (2)
27-34
: Summary: Improved performance metrics trackingThe changes in this file focus on enhancing performance metrics tracking, particularly for shader compilation time. The addition of
compileTime
to theCompositionStatistic
interface and its initialization in theComposition
class constructor provide more detailed insights into the composition's performance.These changes should allow for better performance monitoring and optimization of shader compilation processes. However, ensure that the removal of
precompileTime
doesn't negatively impact any existing systems or debugging processes that may have relied on this metric.Also applies to: 256-261
256-261
: Verify the impact of removing precompileTime.The initialization of
compileTime
to 0 aligns well with the changes in theCompositionStatistic
interface. This is a good addition for tracking shader compilation time.Please confirm that the removal of
precompileTime
doesn't negatively impact any existing performance monitoring or debugging processes. If it was used elsewhere in the codebase, those occurrences should be updated or removed as well.packages/effects/src/player.ts (1)
387-388
: LGTM: Introduced performance measurement for shader compilation.This change adds a timestamp before shader compilation, which will be used to calculate the compilation time. This aligns well with the PR objective of adding compilation time statistics.
web-packages/demo/src/single.ts
Outdated
} catch (e) { | ||
console.error('biz', e); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Enhance error handling for better debugging and user feedback
While the current error handling logs errors to the console, consider enhancing it to provide more detailed information and better user feedback.
Here's a suggested improvement:
} catch (e) {
console.error('Error loading scene:', e);
// Provide user feedback
const errorMessage = e instanceof Error ? e.message : 'An unknown error occurred';
alert(`Failed to load scene: ${errorMessage}`);
// Reset UI state
container?.classList.remove('active');
}
This enhancement:
- Provides more context in the console error.
- Displays a user-friendly error message.
- Resets the UI state in case of an error.
Additionally, consider implementing a more robust error handling strategy, such as using a dedicated error logging service for production environments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Outside diff range and nitpick comments (2)
web-packages/demo/html/single.html (2)
10-29
: CSS changes enhance user experience and readability.The modifications to the
.container
class and the addition of the.container.active
class create a smooth transition effect for showing/hiding the container. Theul
styling improves the readability of the statistics.Consider adding a
transition
property foropacity
to make the fade-in/out effect smoother:.container { /* ... existing properties ... */ - transition: transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out, opacity 0.5s ease-in-out; /* ... */ }
33-37
: HTML structure changes improve user interaction and data display.The addition of the heading, statistics list, and play button enhances the user interface and provides necessary elements for displaying compilation time statistics and triggering scene loading.
To improve accessibility, consider adding an
aria-label
to the button:- <button id="J-button" style="height: 32px; width: 100px;">播放</button> + <button id="J-button" style="height: 32px; width: 100px;" aria-label="Play scene">播放</button>
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (3)
- packages/effects/src/player.ts (2 hunks)
- web-packages/demo/html/single.html (1 hunks)
- web-packages/demo/src/single.ts (1 hunks)
Files skipped from review as they are similar to previous changes (2)
- packages/effects/src/player.ts
- web-packages/demo/src/single.ts
Additional comments not posted (1)
web-packages/demo/html/single.html (1)
Line range hint
1-42
: Changes successfully implement compilation time statistics feature.The modifications to this file align well with the PR objective of adding compilation time statistics. The new HTML elements (statistics list and play button) provide the necessary structure for displaying and triggering the compilation time tracking. The CSS changes create a smooth user experience for showing/hiding the statistics container.
To ensure the new elements are properly utilized, let's verify the corresponding JavaScript implementation:
Verification successful
Compilation time tracking implementation verified.
The codebase successfully implements compilation time tracking as described in the PR. Key findings include:
The 'J-statistic' and 'J-button' elements in web-packages/demo/src/single.ts are used for displaying and triggering the compilation time statistics.
Compilation time tracking logic is implemented across multiple files:
- packages/effects-webgl/src/gl-shader-library.ts
- packages/effects-core/src/render/shader.ts
- packages/effects-core/src/composition.ts
- packages/effects/src/player.ts
The implementation uses 'compileTime' as the main variable for tracking compilation time, and performance measurement is done using the performance.now() method.
The main player file (packages/effects/src/player.ts) logs the compilation time, which aligns with the PR's objective of adding compilation time statistics.
These changes effectively implement the compilation time statistics feature as described in the PR title.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of new HTML elements in the JavaScript code. # Test 1: Check for the usage of 'J-statistic' id echo "Checking for 'J-statistic' usage:" rg --type ts "J-statistic" ../src/ # Test 2: Check for the usage of 'J-button' id echo "Checking for 'J-button' usage:" rg --type ts "J-button" ../src/ # Test 3: Check for compilation time tracking logic echo "Checking for compilation time tracking logic:" rg --type ts "compilation.*time|compile.*duration" ../src/Length of output: 532
Script:
#!/bin/bash # Description: Locate all TypeScript files and verify the usage of new HTML elements and compilation time tracking logic. echo "Locating all TypeScript files:" ts_files=$(fd --type f --extension ts) echo "$ts_files" if [ -z "$ts_files" ]; then echo "No TypeScript files found in the repository." exit 1 fi # Test 1: Check for the usage of 'J-statistic' id echo "Checking for 'J-statistic' usage in TypeScript files:" echo "$ts_files" | xargs rg "J-statistic" # Test 2: Check for the usage of 'J-button' id echo "Checking for 'J-button' usage in TypeScript files:" echo "$ts_files" | xargs rg "J-button" # Test 3: Check for compilation time tracking logic echo "Checking for compilation time tracking logic in TypeScript files:" echo "$ts_files" | xargs rg "compilation.*time|compile.*duration"Length of output: 176538
Script:
#!/bin/bash # Description: Locate all TypeScript files and verify alternative compilation time tracking logic. echo "Locating all TypeScript files:" ts_files=$(fd --type f --extension ts) echo "$ts_files" if [ -z "$ts_files" ]; then echo "No TypeScript files found in the repository." exit 1 fi # Test 1: Check for the usage of 'J-statistic' id echo "Checking for 'J-statistic' usage in TypeScript files:" echo "$ts_files" | xargs rg "J-statistic" # Test 2: Check for the usage of 'J-button' id echo "Checking for 'J-button' usage in TypeScript files:" echo "$ts_files" | xargs rg "J-button" # Test 3: Check for alternative compilation time tracking logic echo "Checking for alternative compilation time tracking logic in TypeScript files:" echo "$ts_files" | xargs rg "build.*time|build_duration|compileTime|compilationDuration|timeTracker|performanceMetrics"Length of output: 177206
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 6
Outside diff range and nitpick comments (4)
web-packages/demo/html/shader-compile.html (2)
1-6
: Consider aligning language declaration with content language.The
<html>
tag declares the language as English, but the title and button text are in Chinese. This might affect accessibility and SEO.Consider changing the language declaration to match the primary language of the content:
-<html lang="en"> +<html lang="zh">Alternatively, if the content is meant to be multilingual, consider using language attributes for specific elements:
<title lang="zh">Shader 编译测试 - demo</title> <button id="J-button" lang="zh" style="height: 32px; width: 100px;">播放</button>Also applies to: 32-37
33-33
: Clarify the purpose of the statistics element.The purpose of the
<dl>
element with id "J-statistic" is not immediately clear.Consider adding a descriptive heading or comment to clarify its purpose:
+<!-- Statistics for shader compilation --> <dl id="J-statistic"></dl>
web-packages/demo/index.html (1)
16-16
: LGTM! Consider standardizing language usage.The addition of the "Shader 编译测试" link is appropriate and aligns well with the PR's objective of introducing compilation time statistics. The placement within the existing list of demo links is logical.
For consistency, consider standardizing the language used in link texts. Some links are in English while others, including the new one, are in Chinese. If there's no specific reason for mixing languages, it might be beneficial to choose one language for all link texts.
For example, you could change it to:
- <a class="am-list-item" href="html/shader-compile.html">Shader 编译测试</a> + <a class="am-list-item" href="html/shader-compile.html">Shader Compilation Test</a>Or, if Chinese is preferred:
- <a class="am-list-item" href="html/shader-compile.html">Shader 编译测试</a> + <a class="am-list-item" href="html/shader-compile.html">着色器编译测试</a>web-packages/demo/src/shader-compile.ts (1)
1-20
: Consider adding type declaration and cleaning up commented code
Add a type declaration for the
json
constant to improve code clarity:const json: string[] = [ // ... existing URLs ... ];The presence of multiple commented-out JSON URLs suggests different test scenarios. Consider moving these to a configuration file or creating separate test cases for each scenario.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (5)
- packages/effects/src/player.ts (2 hunks)
- web-packages/demo/html/shader-compile.html (1 hunks)
- web-packages/demo/index.html (1 hunks)
- web-packages/demo/src/shader-compile.ts (1 hunks)
- web-packages/demo/vite.config.js (1 hunks)
Files skipped from review as they are similar to previous changes (1)
- packages/effects/src/player.ts
Additional comments not posted (2)
web-packages/demo/html/shader-compile.html (1)
39-39
: Ensure browser compatibility for module scripts.The use of
type="module"
for script loading is a modern approach, but it may not be supported in older browsers.Consider adding a fallback for browsers that don't support ES modules:
<script type="module" src="../src/shader-compile.ts"></script> +<script nomodule src="../src/shader-compile-legacy.js"></script>
Also, verify that the TypeScript compilation process is set up correctly to output JavaScript that can be directly consumed by browsers.
Run the following script to check for TypeScript configuration:
web-packages/demo/vite.config.js (1)
27-27
: New entry for shader compilation looks good.The addition of 'shader-compile' as a new entry in the
rollupOptions.input
object is consistent with the existing structure and aligns with the PR objective of adding compilation time statistics. This change will include the newshader-compile.html
file in the build process, making it accessible in the application.To ensure the new HTML file exists and is properly referenced, let's run the following verification script:
#!/bin/bash # Description: Verify the existence of the shader-compile.html file and its contents # Test 1: Check if the file exists if fd -p "html/shader-compile.html" ; then echo "shader-compile.html file found." else echo "Error: shader-compile.html file not found." exit 1 fi # Test 2: Check if the file contains relevant content if rg -q "shader|compile|performance" "html/shader-compile.html"; then echo "shader-compile.html contains relevant content." else echo "Warning: shader-compile.html might not contain expected content." fi
<style> | ||
html, body, div, canvas { margin: 0; padding: 0; } | ||
.container { | ||
visibility: hidden; | ||
opacity: 0; | ||
width: 188px; | ||
height: 334px; | ||
position: fixed; | ||
bottom: 0%; | ||
left: 50%; | ||
transform: translate(-50%, 0) scale(0); | ||
transition: transform 0.5s ease-in-out; | ||
background-color: rgba(0,0,0,255); | ||
} | ||
.container.active { | ||
visibility: visible; | ||
z-index: -1; | ||
opacity: 1; | ||
transform: translate(-50%, 0) scale(1); | ||
} | ||
ul { | ||
background-color: rgba(255,255,255,0.5); | ||
} | ||
</style> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Consider enhancing CSS for better maintainability and user experience.
While the current CSS is functional, there are opportunities for improvement:
- The container's background is set to solid black (
rgba(0,0,0,255)
), which might affect content visibility. - The z-index of -1 on the active container might cause layering issues.
- The styles could benefit from using CSS variables for better maintainability.
Consider the following improvements:
<style>
html, body, div, canvas { margin: 0; padding: 0; }
+ :root {
+ --container-width: 188px;
+ --container-height: 334px;
+ --container-bg: rgba(0, 0, 0, 0.8);
+ --transition-duration: 0.5s;
+ }
.container {
visibility: hidden;
opacity: 0;
- width: 188px;
- height: 334px;
+ width: var(--container-width);
+ height: var(--container-height);
position: fixed;
bottom: 0%;
left: 50%;
transform: translate(-50%, 0) scale(0);
- transition: transform 0.5s ease-in-out;
- background-color: rgba(0,0,0,255);
+ transition: transform var(--transition-duration) ease-in-out, opacity var(--transition-duration) ease-in-out;
+ background-color: var(--container-bg);
}
.container.active {
visibility: visible;
- z-index: -1;
+ z-index: 1;
opacity: 1;
transform: translate(-50%, 0) scale(1);
}
ul {
- background-color: rgba(255,255,255,0.5);
+ background-color: rgba(255, 255, 255, 0.8);
}
</style>
These changes improve readability, maintainability, and potentially the visual appearance of the interface.
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
<style> | |
html, body, div, canvas { margin: 0; padding: 0; } | |
.container { | |
visibility: hidden; | |
opacity: 0; | |
width: 188px; | |
height: 334px; | |
position: fixed; | |
bottom: 0%; | |
left: 50%; | |
transform: translate(-50%, 0) scale(0); | |
transition: transform 0.5s ease-in-out; | |
background-color: rgba(0,0,0,255); | |
} | |
.container.active { | |
visibility: visible; | |
z-index: -1; | |
opacity: 1; | |
transform: translate(-50%, 0) scale(1); | |
} | |
ul { | |
background-color: rgba(255,255,255,0.5); | |
} | |
</style> | |
<style> | |
html, body, div, canvas { margin: 0; padding: 0; } | |
:root { | |
--container-width: 188px; | |
--container-height: 334px; | |
--container-bg: rgba(0, 0, 0, 0.8); | |
--transition-duration: 0.5s; | |
} | |
.container { | |
visibility: hidden; | |
opacity: 0; | |
width: var(--container-width); | |
height: var(--container-height); | |
position: fixed; | |
bottom: 0%; | |
left: 50%; | |
transform: translate(-50%, 0) scale(0); | |
transition: transform var(--transition-duration) ease-in-out, opacity var(--transition-duration) ease-in-out; | |
background-color: var(--container-bg); | |
} | |
.container.active { | |
visibility: visible; | |
z-index: 1; | |
opacity: 1; | |
transform: translate(-50%, 0) scale(1); | |
} | |
ul { | |
background-color: rgba(255, 255, 255, 0.8); | |
} | |
</style> |
const container = document.getElementById('J-container'); | ||
|
||
document.getElementById('J-button')!.addEventListener('click', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Improve error handling for DOM element selection
Consider adding checks to ensure DOM elements exist before using them:
const container = document.getElementById('J-container');
const button = document.getElementById('J-button');
if (!container || !button) {
console.error('Required DOM elements not found');
// Handle the error appropriately
return;
}
button.addEventListener('click', () => {
// ... existing code ...
});
This approach prevents potential runtime errors and provides better error feedback.
const player = new Player({ | ||
container, | ||
// renderFramework: 'webgl2', | ||
}); | ||
const compositions = await player.loadScene(Array.isArray(json) ? json : [json]) as unknown as Composition[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Refine type handling and error management
-
The type assertion
as unknown as Composition[]
suggests a potential type mismatch. Consider updating theloadScene
method's return type or use a type guard instead of assertion:const compositions = await player.loadScene(Array.isArray(json) ? json : [json]); if (!Array.isArray(compositions) || !compositions.every(c => c instanceof Composition)) { throw new Error('Invalid composition data received'); }
-
Implement more specific error handling to provide better feedback:
try { // ... existing code ... } catch (e) { if (e instanceof Error) { console.error(`Failed to load scene: ${e.message}`); } else { console.error('An unknown error occurred while loading the scene'); } // Consider updating UI to reflect the error state }
compositions.forEach(composition => { | ||
const dt = document.createElement('dt'); | ||
|
||
dt.innerHTML = `>>> composition: ${composition.name}`; | ||
document.getElementById('J-statistic')?.appendChild(dt); | ||
|
||
for (const key in composition.statistic) { | ||
const p = document.createElement('dd'); | ||
|
||
// @ts-expect-error | ||
p.innerHTML = `${key}: ${composition.statistic[key]}`; | ||
document.getElementById('J-statistic')?.appendChild(p); | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Enhance performance, security, and error handling in statistics display
-
For better performance with large datasets, consider using
DocumentFragment
:const fragment = document.createDocumentFragment(); compositions.forEach(composition => { // ... create elements and append to fragment }); document.getElementById('J-statistic')?.appendChild(fragment);
-
Add a check for the existence of the statistics container:
const statisticContainer = document.getElementById('J-statistic'); if (!statisticContainer) { console.error('Statistics container not found'); return; }
-
To prevent potential XSS vulnerabilities, use
textContent
instead ofinnerHTML
:dt.textContent = `>>> composition: ${composition.name}`; // ... p.textContent = `${key}: ${composition.statistic[key]}`;
-
Consider creating a dedicated function for creating statistic elements to improve readability and maintainability.
document.getElementById('J-button')!.addEventListener('click', () => { | ||
(async () => { | ||
try { | ||
container?.classList.add('active'); | ||
|
||
const player = new Player({ | ||
container, | ||
// renderFramework: 'webgl2', | ||
}); | ||
const compositions = await player.loadScene(Array.isArray(json) ? json : [json]) as unknown as Composition[]; | ||
|
||
compositions.forEach(composition => { | ||
const dt = document.createElement('dt'); | ||
|
||
dt.innerHTML = `>>> composition: ${composition.name}`; | ||
document.getElementById('J-statistic')?.appendChild(dt); | ||
|
||
for (const key in composition.statistic) { | ||
const p = document.createElement('dd'); | ||
|
||
// @ts-expect-error | ||
p.innerHTML = `${key}: ${composition.statistic[key]}`; | ||
document.getElementById('J-statistic')?.appendChild(p); | ||
} | ||
}); | ||
} catch (e) { | ||
console.error('biz', e); | ||
} | ||
})(); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Improve overall structure and error handling
-
Consider extracting the main functionality into a separate async function for better readability and testability:
async function loadAndDisplayCompositions() { try { // ... existing code ... } catch (e) { handleError(e); } } function handleError(e: unknown) { console.error('Failed to load or display compositions:', e); // Update UI to show error message to the user const errorMessage = e instanceof Error ? e.message : 'An unknown error occurred'; document.getElementById('J-error-message')?.textContent = errorMessage; } document.getElementById('J-button')?.addEventListener('click', loadAndDisplayCompositions);
-
Add appropriate loading and error states to improve user experience:
function showLoading(isLoading: boolean) { const loadingElement = document.getElementById('J-loading'); if (loadingElement) { loadingElement.style.display = isLoading ? 'block' : 'none'; } } async function loadAndDisplayCompositions() { showLoading(true); try { // ... existing code ... } catch (e) { handleError(e); } finally { showLoading(false); } }
These changes will improve the code's structure, error handling, and user experience.
@@ -24,6 +24,7 @@ export default defineConfig(({ mode }) => { | |||
'dynamic-image': resolve(__dirname, 'html/dynamic-image.html'), | |||
'dynamic-video': resolve(__dirname, 'html/dynamic-video.html'), | |||
'render-level': resolve(__dirname, 'html/render-level.html'), | |||
'shader-compile': resolve(__dirname, 'html/shader-compile.html'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Compilation time tracking not implemented
The shader-compile.html
file does not include any implementation for compilation time tracking. Please add the necessary code to enable tracking of compilation time as per the PR objectives.
Analysis chain
Reminder: Implement compilation time tracking
While this configuration change correctly includes the new shader-compile.html file, ensure that the actual implementation of compilation time tracking is present in the HTML file or its associated JavaScript. This is crucial to meet the PR objective of adding compilation time statistics.
To verify the implementation of compilation time tracking, let's check the contents of the shader-compile.html file:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for compilation time tracking implementation in shader-compile.html
# Search for keywords related to time tracking in the shader-compile.html file
rg -i "time|duration|performance|measure" "html/shader-compile.html"
Length of output: 228
Script:
#!/bin/bash
# Description: Locate the shader-compile.html file in the repository
fd "shader-compile\.html$" .
Length of output: 75
Script:
#!/bin/bash
# Description: Verify compilation time tracking implementation in shader-compile.html
rg -i "time|duration|performance|measure" "./web-packages/demo/html/shader-compile.html"
Length of output: 88
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Style