Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Glow backend #210

Merged
merged 96 commits into from
Mar 21, 2022
Merged

Glow backend #210

merged 96 commits into from
Mar 21, 2022

Conversation

asny
Copy link
Owner

@asny asny commented Mar 21, 2022

No description provided.

asny added 30 commits March 11, 2022 21:34
asny added 23 commits March 20, 2022 21:41
@asny
Bump version
3e784ec
@asny
texture read other formats than RGBA
d9140a0
@asny
Save pixels/read color takes/returns Vec<[u8; 4]>
a983099
@asny
Fix reading other formats than RGBA on web
7223628
@asny
Move and rename internal function
96e38dd
@asny
RenderTarget read_color
2f8217a
@asny
Docs
f8cae11
@asny
Error check after read
3a89aab
@asny
Move data type definitions to data_type.rs
b8ad53c
@asny
RenderTarget::screen
d9ecfc4
@asny
render target read_depth
3be5c7e
@asny
Picking target texture is one float
4a3e494
@asny
PrimitiveDataType impl Default
dbc0533
@asny
Check byte length when filling texture
771622f
@asny
Remove ogl and wgl
f50cf04
@asny
Docs
2eb9f4a
@asny
Docs
0e03975
@asny
More docs
90ea4a8
@asny
CpuElementBuffer -> Indices
8c8f858
@asny
Panic if format and generic data type doesn't match for deprecated co…
3297c83 
…lor target texture
@asny
Minor clean-up
26b6ba3
@asny
Minor clean-up
eeb262a
@asny
Move
3978972
@asny asny merged commit 4097290 into master Mar 21, 2022
@asny asny deleted the glow-backend branch March 21, 2022 19:37
emilk added a commit to emilk/egui that referenced this pull request Mar 22, 2022
@emilk
Add example using three-d
fe3e317 
https://github.com/asny/three-d recently merged a PR adding
`glow` support: asny/three-d#210
This means it is a prime candidate for embedding 3D painting inside
an eframe app.

There are currently a few kinks that need to be figured out:

### Black screen
When reusing the same three_d context over time (as one should),
we only get one frame of egui together with three_d, and then after that
a black screen with just the three_d painting on top.

I need to fix that before merging this PR.

### `Shape: Send + Sync`
`Shape` is `Send + Sync` and `three_d::Context` is not. This means
we cannot store a three_d context and send it to the `Shape::Callback`.

So we either need to recreate the three_d context each frame (obviously
a bad idea), or access it through a `thread_local` hack.
This PR adds both as examples, with a checkbox to switch.

We could consider making `Shape: !Send + !Sync`, but that would mean
`egui::Context` could not be `Send+Sync` either (because the egui
context stores shapes). This could actually be fine. `egui::Context`
should only be used from a background thread for calling request_repaint
and allocating textures. These could be made separate parts of the
egui Context, so that one would do:

``` rust

let repaint_signal = egui_ctx.repaint_signal();
let tex_mngr = egui_ctx.tex_mngr();
std::thread::spawn(move || {
    // We can use repaint_signal and tex_mngr here,
    // but NOT `egui_ctx`.
}):

Related:
* #1379
* #1380
* #1389
emilk added a commit to emilk/egui that referenced this pull request Mar 22, 2022
@emilk
Add example using three-d
88c5947 
https://github.com/asny/three-d recently merged a PR adding
`glow` support: asny/three-d#210
This means it is a prime candidate for embedding 3D painting inside
an eframe app.

There are currently a few kinks that need to be figured out:

When reusing the same three_d context over time (as one should),
we only get one frame of egui together with three_d, and then after that
a black screen with just the three_d painting on top.

I need to fix that before merging this PR.

`Shape` is `Send + Sync` and `three_d::Context` is not. This means
we cannot store a three_d context and send it to the `Shape::Callback`.

So we either need to recreate the three_d context each frame (obviously
a bad idea), or access it through a `thread_local` hack.
This PR adds both as examples, with a checkbox to switch.

We could consider making `Shape: !Send + !Sync`, but that would mean
`egui::Context` could not be `Send+Sync` either (because the egui
context stores shapes). This could actually be fine. `egui::Context`
should only be used from a background thread for calling request_repaint
and allocating textures. These could be made separate parts of the
egui Context, so that one would do:

``` rust

let repaint_signal = egui_ctx.repaint_signal();
let tex_mngr = egui_ctx.tex_mngr();
std::thread::spawn(move || {
    // We can use repaint_signal and tex_mngr here,
    // but NOT `egui_ctx`.
}):

Related:
* #1379
* #1380
* #1389
@emilk emilk mentioned this pull request Mar 22, 2022
Closed
4 tasks
emilk added a commit to emilk/egui that referenced this pull request Mar 22, 2022
@emilk
Add example using three-d
ad0129d 
https://github.com/asny/three-d recently merged a PR adding
`glow` support: asny/three-d#210
This means it is a prime candidate for embedding 3D painting inside
an eframe app.

There are currently a few kinks that need to be figured out:

When reusing the same three_d context over time (as one should),
we only get one frame of egui together with three_d, and then after that
a black screen with just the three_d painting on top.

I need to fix that before merging this PR.

`Shape` is `Send + Sync` and `three_d::Context` is not. This means
we cannot store a three_d context and send it to the `Shape::Callback`.

So we either need to recreate the three_d context each frame (obviously
a bad idea), or access it through a `thread_local` hack.
This PR adds both as examples, with a checkbox to switch.

We could consider making `Shape: !Send + !Sync`, but that would mean
`egui::Context` could not be `Send+Sync` either (because the egui
context stores shapes).

This is discussed in #1399
emilk added a commit to emilk/egui that referenced this pull request Mar 22, 2022
@emilk
Add example using three-d
9455851 
https://github.com/asny/three-d recently merged a PR adding
`glow` support: asny/three-d#210
This means it is a prime candidate for embedding 3D painting inside
an eframe app.

There are currently a few kinks that need to be figured out:

When reusing the same three_d context over time (as one should),
we only get one frame of egui together with three_d, and then after that
a black screen with just the three_d painting on top.

I need to fix that before merging this PR.

`Shape` is `Send + Sync` and `three_d::Context` is not. This means
we cannot store a three_d context and send it to the `Shape::Callback`.

So we either need to recreate the three_d context each frame (obviously
a bad idea), or access it through a `thread_local` hack.
This PR adds both as examples, with a checkbox to switch.

We could consider making `Shape: !Send + !Sync`, but that would mean
`egui::Context` could not be `Send+Sync` either (because the egui
context stores shapes).

This is discussed in #1399
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@asny